This is what my initial patch addressed. If opcode_t is always 32 bits, but
we allow the native integer type to be 64 bits, then we cannot have inlined
integers. Instead, we have to move the integers out into the constant
section. Therefore, it would seem that we must force sizeof( opcode_t) ==
sizeof( intval ) or do some chicanery with splitting the 64 bit integer up
into two 32 bit integers, but that gets really ugly.
-----Original Message-----
From: Andy Dougherty
To: Dan Sugalski
Cc: [EMAIL PROTECTED]
Sent: 10/4/2001 12:25 PM
Subject: Re: moving integer constants to the constant table
On Thu, 4 Oct 2001, Dan Sugalski wrote:
> > > Sort of. They're guaranteed to be as big as the native integer
you've
> > > chosen to build Parrot with, and at least 32 bits.
> >
> >Ok, but does "long long" count as a "native integer"?
>
> Yup, if that's what you configured perl with.
Ok, last question for today: Do we want to require sizeof(opcode_t) ==
sizeof(INTVAL)? A user may know he wants 'long long' integer constants,
but also know that opcodes will always fit in 32-bits and want to use
'int' for opcode_t (for compactness and possibly speed).
On the one hand, I could see allowing different sizes as a reasonable
position. On the other hand, I could also see forbidding different
sizes
as a reasonable position. I don't have a gripping hand, so I don't see
any other possibilities at the moment :-).
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
