This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed:
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Randall R Schulz'" <rrschulz at cris dot com>, "Boehm, Hans" <hans_boehm at hp dot com>, "'tprince at computer dot org'" <tprince at computer dot org>, tromey at redhat dot com
- Cc: "Billinghurst, David (CRTS)" <David dot Billinghurst at riotinto dot com>, java at gcc dot gnu dot org, cygwin at cygwin dot com
- Date: Mon, 6 May 2002 14:50:32 -0700
- Subject: RE: Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed:
> From: Randall R Schulz [mailto:rrschulz@cris.com]
>
> Is there a reason that the three bits used for lock
> management must be the
> least significant three? The XSB interpreter (XSB is a Prolog
> system) uses
> even more bits, but doesn't demand that they be contiguous.
> Depending on
> the processor, machine and OS architecture, the tag bits XSB
> needs (which
> are classic data type tags) can be split and reassembled as needed.
> Naturally, it can get costly to do this, but I assume that it
> maximizes the
> set of systems on which XSB can run while preserving as many bits as
> possible for the actual (type-tagged) data values stored.
>
> Is there a reason a more flexible approach to "stolen" bits
> cannot be taken
> by GCJ?
Not that I know of. I think it would be fairly easy to make this
configurable. The code shouldn't rely on the position of those bits anyway,
and I believe it doesn't.
This may help with some embedded applications. Otherwise I'm not sure it
would buy you much. On 64-bit processore, 8-byte alignment is generally
required anyway. On 32-bit processors, I don't think you want to limit the
address space any more than it already is.
My guess is that allowing the code to be configured to require only 8 byte
object spacing (by simply dropping the low order bits in the locking code)
is a more general solution.
Hans
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/