Re: Parrot coredumps on Solaris 8

2001-09-12 Thread Philip Kendall
() loop. That was the padding problem, which is now fixed in CVS (Brian Wheeler's patch in http://archive.develooper.com/perl6-internals%40perl.org/msg03844.html ) test3.pbc is still segfaulting on me though. Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

Parrot coredumps on Solaris 8

2001-09-11 Thread Philip Kendall
going to have to do some digging? Cheers, Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

Re: parrot compilation failure in Tru64

2001-09-15 Thread Philip Kendall
bit on-disc format into a 64 bit format in memory before reading it on a platform with 64 bit IVs? Cheers, Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

Re: parrot compilation failure in Tru64

2001-09-15 Thread Philip Kendall
mentioned, there are platforms (eg Cray) which don't have a native 32-bit integer type. OTOH, my impression is that Dan is favouring at least some sort of bytecode portability. Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)

2001-09-12 Thread Philip Kendall
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 >

Re: Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)

2001-09-12 Thread Philip Kendall
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote: [Coredumps on Alpha] > 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

Re: parrot compilation failure in Tru64

2001-09-15 Thread Philip Kendall
y using int as the IV type instead of long. That won't work though, due to our typecasting between pointers and IVs. I did at one stage patch the entire thing to use int32_t for the bytecode rather than IV, but... as Simon has said, we need to work out what we want to do to fix this before

Re: Using int32_t instead of IV for code

2001-09-14 Thread Philip Kendall
l exists that we might > shrink to 16 bit opcodes...) That should be possible from my patch just by replacing all occurences of `int32_t' with `OP' (and then getting something into the configure system to set the typedef). Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

Re: Using int32_t instead of IV for code

2001-09-13 Thread Philip Kendall
On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote: > At 05:06 PM 9/12/2001 -0700, Hong Zhang wrote: > > >I think we should use int32_t instead of IV for all code related > >data. > > Absolutely. Using an IV was a quick answer to get things working--a first > draft if you will. It nee

Re: The core platforms list

2001-09-18 Thread Philip Kendall
(Sparc) 32 bit, 64 bit or both? Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

Re: Using int32_t instead of IV for code

2001-09-13 Thread Philip Kendall
be the same width as a pointer, so we can freely typecast between the two. Also, if we've got a system with 64 bit IVs, are the arguments to Parrot opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any way of loading a 64 bit constant? Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/

config.h.in

2001-09-13 Thread Philip Kendall
Two small changes to config.h.in: * Actually use ${nv} for the numeric type, rather than `${iv} double'. * Make MASK_CHUNK_LOW_BITS 64 bit clean. Phil Index: config.h.in === RCS file: /home/perlcvs/parrot/config.h.in,v retrieving r