Re: [Gcl-devel] Re: gcl/maxima on hppa

[LaMont Jones]

On Thu, Aug 01, 2002 at 02:44:12PM -0400, Camm Maguire wrote:
> > 16 byte alignment is certainly nicer, and may be required on hppa-linux,
> > but I don't know.
> What are the atomic issues with 16 byte alignment?

LDCW (load and clear word) is only defined on addresses that are 16-byte
aligned.

> > That would be the most significant difference  sp (gr30) + 0 and beyond
> > is off the end of the stack....
> Does this refer to the start of the heap, ~ 0x20000 on hppa-linux?

No.  interrupts, function calls, and such eventually allocate a stack
frame, which is done by _ADDING_ to %sp, and then storing things at
negative offsets from the new %sp.

> Yes, this assembly is likely what I need.  I don't really care if I
> get the state before or after the function call, as long as I can find
> the addresses of all local variables normally intended for the stack
> in some definiable region of memory.  Consider the following gdb
> session.  Certain local variables cannot report their addresses under
> gdb.  I assume this means that these addresses are also not to be
> found on the stack, causing my garbage collector to overlook them in
> the mark stage, and erroneously sweep them away.

OK.  I'll let willy correct me, but if you wrote a stub that spilled
gr3-18 to the frame, and then called your garbage collector, then you
could find the registers on the stack somewhere...

The stack layout looks like:  [old sp],register spill, local vars, args
for function calls, [new sp].

>   (On ia64, there was
> a special __builtin_flushrs() function which would copy these
> registers to a defined stack area.  Adding this command and the new
> stack area to the garbage collector completed the gcl/maxima port to
> ia64.  I think I need something analogous here.)

Sounds like a gcc 3.0 enhancement potential....

Failing that, if you want to call foo, then call bar as below:

(As long as you have < 4 no-bigger-than-32-bit args, foo and bar have
the same function declaration.  If you need more, holler and I can add
that part...)

Or, if you want a function that foo can call, let me know.  Either way,
at least some of the register vars will wind up on the stack between
stack base and current %sp.  (foo probably spills at least one of the
regs in it's frame...)

This stub should compile & work on hp-ux as well, if you so care...

lamont

============================
        .code
        .export bar,entry
        .import foo,code
        .proc
        .callinfo entry_gr=18, calls, save_rp
        .label  bar
        .entry
        stw     %rp,-20(%sp)
        stwm    %r3,128(%sp)
        stw     %r4,-124(%sp)
        stw     %r5,-120(%sp)
        stw     %r6,-116(%sp)
        stw     %r7,-112(%sp)
        stw     %r8,-108(%sp)
        stw     %r9,-104(%sp)
        stw     %r10,-100(%sp)
        stw     %r11,-96(%sp)
        stw     %r12,-92(%sp)
        stw     %r13,-88(%sp)
        stw     %r14,-84(%sp)
        stw     %r15,-80(%sp)
        stw     %r16,-76(%sp)
        stw     %r17,-72(%sp)
        stw     %r18,-68(%sp)
        bl      foo,%rp
        nop
        ldw     -148(%sp),%rp
        ldw     -72(%sp),%r18
        ldw     -68(%sp),%r17
        ldw     -76(%sp),%r16
        ldw     -80(%sp),%r15
        ldw     -84(%sp),%r14
        ldw     -88(%sp),%r13
        ldw     -92(%sp),%r12
        ldw     -96(%sp),%r11
        ldw     -100(%sp),%r10
        ldw     -104(%sp),%r9
        ldw     -108(%sp),%r8
        ldw     -112(%sp),%r7
        ldw     -116(%sp),%r6
        ldw     -120(%sp),%r5
        ldw     -124(%sp),%r4
        bv      0(%rp)
        ldwm    128(%sp),%r3

        .exit
        .procend
        .end
============================