Re: [Gcl-devel] Re: gcl/maxima on hppa
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
============================
Reply to: