On Wed, Sep 12, 2001 at 02:54:49PM +0100, Philip Kendall wrote:
> On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
> > At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
> > >
> > >Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> > >read_constants_table on my Alpha. Problems with the integer-pointer
> > >conversions in memory.c? (line 29 is giving me a warning).
> >
> > You've got 64-bit ints and pointers? Or are the ints 32 bits? I haven't
> > abused things enough to run on my VMS Alpha boxes recently.
>
> ints are 32 bit, but IVs and pointers are both 64 bit. I've just backed
> out the changes to memory.c and it still segfaults in the same place;
> make of that what you will...
Quick research reveals the obvious problem: even when IVs are 64 bit,
assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
Changing this over to 'q' means I get further, but it's still
segfaulting further in, which I'll look at in a bit.
Are we going to try and support 32 bit IVs on machines with 64 bit
pointers? If so, all the places in the code where pointers are typecast
to IVs are clearly going to blow everything up in a hurry...
In the short to medium term, should Configure.pl modify the behaviour of
assemble.pl such that it produces the correct sized bytecode? Also, is
there going to be a mechanism to identify if we're trying to run
bytecode with the wrong sized and/or endianness words?
Cheers,
Phil
--
Philip Kendall <[EMAIL PROTECTED]>
http://www.srcf.ucam.org/~pak21/
