(Sparc)
32 bit, 64 bit or both?
Phil
--
Philip Kendall <[EMAIL PROTECTED]>
http://www.srcf.ucam.org/~pak21/
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
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/
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/
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/
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
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
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/
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
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
>
() 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/
going to have to do some
digging?
Cheers,
Phil
--
Philip Kendall <[EMAIL PROTECTED]>
http://www.srcf.ucam.org/~pak21/
12 matches
Mail list logo
