gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: LaMont Jones
Subject: [Gcl-devel] Re: gcl/maxima on hppa
Date: Wed, 31 Jul 2002 22:36:44 -0600
User-agent: Mutt/1.3.25i

On Wed, Jul 31, 2002 at 11:50:20PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 31, 2002 at 06:42:47PM -0400, Camm Maguire wrote:
> > Looking over the boehm-gc code, the only unusual item appears to be a
> > requirement to align malloc results on 8 byte boundaries even when
> > running in 32bit mode.  
> surely 16 byte boundaries?  some structs are allocated on the stack,
> which we need to do atomic ops on.  and we can't guarantee atomic ops
> work unless they're 16-byte aligned.

If I let my hp-ux history out a bit, malloc on hp-ux always returns 8-byte
aligned data.  This is because the 32 bit hardware supports 64 bit floats.

16 byte alignment is certainly nicer, and may be required on hppa-linux,
but I don't know.

> > 2) Is there anything unusual about the C stack on hppa?
> it grows upwards instead of downwards?

That would be the most significant difference  sp (gr30) + 0 and beyond
is off the end of the stack....

> > 3) When looking at the situation in a debugger, certain local
> >    variables on the stack cannot report their address, apparently
> >    indicating they are stored in registers.  Is there a way to flush
> >    these reliably to memory before collecting garbage?
> umm.  no idea.

No.  If the variables are in registers, they may get spilled when you
call a function, or may not (depending on how many registers each of
the two routines is using.)

With a little assembly, you can capture all of the registers as they exist
at the time of that call, but that should not be confused with the register
state in the code that called you...   (If that made _ANY_ sense, please
let me know... :-)

lamont



reply via email to

[Prev in Thread] Current Thread [Next in Thread]