On Fri, 7 Oct 2005, Leopold Toetsch wrote:
>
> On Oct 7, 2005, at 20:52, Andy Dougherty wrote:
>
> > perl Configure.pl --optimize=-O3 --debugging=0 --cc=gcc --ld=gcc
> > --link=gcc
>
> ...
> Andy slowly please. No --optimize tests yet. Let's first look at plain default
> build.
Why? --optimize does at least two different things: First, obviously, it
allows the compiler to optimize. This is often a good strategy for
exposing faulty assumptions in code. Second, it enables the
DISABLE_GC_DEBUG define, which changes the sizes of several
structures, including PMCs and Stack_Chunks. Changing the sizes of
those structures can expose alignment and size assumptions.
> > One thing I really don't understand is why the CONTEXT macro has to play
> > the "-1" trick to access memory to the "left".
>
> There is currently just one base pointer (praise x86 jit). Parrot registers
> are to the right of it, context is at the left side (src/inter_create.c has a
> picture describing this).
I know about the picture. I don't know why you chose to use a pointer
pointing to the middle of the structure instead of the beginning. I'm
afraid "praise x86 jit" doesn't mean anything to me.
> > Similarly, I don't
> > understand why the ALIGNED_CTX_SIZE macro has a NUMVAL_SIZE buried in it,
> > and how that fits in with attempting to do things like p[-1].
>
> Context + registers are allocated as one chunk. Registers especially the
> FLOATVAL ones have to be aligned at FLOATVAL alignment needs. Therefore there
> can be a gap between the context and the registers. Above macro takes care
> about this fact by increasing the allocation size.
But you don't include the gap in your picture, and the code actually
assumes that the gap is at the beginning of the chunk, not in the middle
as you indicate here. Placing the gap at the beginning allows p[-1] to
work, but then runs into the problem that the context structures might, in
principle, be incorrectly aligned. I also don't know if there are
any garbage collection issues, since we don't actually carry around a
pointer to the beginning of the allocated chunk -- but that may
simply be my ignorance of garbage collection.
(This isn't an issue now because, at least for the default configuration
on common architectures, ALIGNED_CTX_SIZE == sizeof(struct
Parrot_Context), so there actually isn't any padding at all. Further,
since the Parrot_Context structure consists of integers and pointers, its
alignment constraints are easily satisfied.)
If, instead, you allocated a single structure containing both the Context
plus the registers, then the compiler would correctly ensure all the
correct padding and compute all the offsets for you.
> I don't think that current failures are related to this at all - see
> explanation for above errors. It's of course true that optimized build will
> cause more troubles, but we'll have a look at these later.
You may well be right, since there is actually 0 padding at present.
However, the tests in question worked in the trunk before the merge, and
fail after it, so this was a natural place to look. Also, alignment
issues have been at the root of a number of problems in the past, gcc
warned about aliasing problems with the code in this area, and it was just
plain puzzling to me.
None of which is terribly urgent to me, however, as I don't expect to have
time to follow up on this for quite a while.
--
Andy Dougherty [EMAIL PROTECTED]
