Re: [Gcl-devel] Re: gcl/maxima on hppa
Greetings, and thank you for this!
At first glance, this appears to solve the gc issue on hppa! There
may be a residual difficulty, but I won't be sure until the Debian
autobuilder finishes compiling the upload I just made.
In any case, I would appreciate a version 'which foo can call' as you
mention below.
Here is what the current draft looks like, which appears to work but
needs cleaning up a bit:
=============================================================================
#if defined(__hppa__)
asm(
".code\n\t"
".export GBC,entry\n\t"
".import GBC1,code\n\t"
".proc\n\t"
".callinfo entry_gr=18, calls, save_rp\n\t"
".label GBC\n\t"
".entry\n\t"
"stw %rp,-20(%sp)\n\t"
"stwm %r3,128(%sp)\n\t"
"stw %r4,-124(%sp)\n\t"
"stw %r5,-120(%sp)\n\t"
"stw %r6,-116(%sp)\n\t"
"stw %r7,-112(%sp)\n\t"
"stw %r8,-108(%sp)\n\t"
"stw %r9,-104(%sp)\n\t"
"stw %r10,-100(%sp)\n\t"
"stw %r11,-96(%sp)\n\t"
"stw %r12,-92(%sp)\n\t"
"stw %r13,-88(%sp)\n\t"
"stw %r14,-84(%sp)\n\t"
"stw %r15,-80(%sp)\n\t"
"stw %r16,-76(%sp)\n\t"
"stw %r17,-72(%sp)\n\t"
"stw %r18,-68(%sp)\n\t"
"bl GBC1,%rp\n\t"
"nop\n\t"
"ldw -148(%sp),%rp\n\t"
"ldw -72(%sp),%r18\n\t"
"ldw -68(%sp),%r17\n\t"
"ldw -76(%sp),%r16\n\t"
"ldw -80(%sp),%r15\n\t"
"ldw -84(%sp),%r14\n\t"
"ldw -88(%sp),%r13\n\t"
"ldw -92(%sp),%r12\n\t"
"ldw -96(%sp),%r11\n\t"
"ldw -100(%sp),%r10\n\t"
"ldw -104(%sp),%r9\n\t"
"ldw -108(%sp),%r8\n\t"
"ldw -112(%sp),%r7\n\t"
"ldw -116(%sp),%r6\n\t"
"ldw -120(%sp),%r5\n\t"
"ldw -124(%sp),%r4\n\t"
"bv 0(%rp)\n\t"
"ldwm 128(%sp),%r3\n\t"
".exit\n\t"
".procend\n\t"
".end\n\t"
);
void
GBC1(enum type t) {
#else
void
GBC(enum type t) {
#endif
=============================================================================
Take care,
lamont@security.hp.com (LaMont Jones) writes:
> 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
> ============================
>
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: