Ok, after class I will fix and repatch. Making opcode_t a simple type that
is configurable.
Thanks!
Tanton
-----Original Message-----
From: Dan Sugalski
To: Simon Cozens; ''[EMAIL PROTECTED]' '
Sent: 9/19/2001 10:14 AM
Subject: Re: [PATCH] changing IV to opcode_t!!
At 03:58 PM 9/19/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 19, 2001 at 10:59:45AM -0400, Dan Sugalski wrote:
> > Nope. opcode_t should be the native opcode type for the platform
we're
> > compiling on. No need for fancy unions--configure should find out
the
> > integer type that works out right for the platform and the bytecode
and
> use
> > that.
>
>I thought the whole point was that on some platforms there *isn't* an
>integer type that works right.
Nope. There's *always* an integer type that works right. We won't be
running on a platform that doesn't have 32-bit integers. (Well, not
without
someone hacking the heck out of the core)
The bytecode stream on disk is a series of M-bit integers holding 32-bit
opcodes and parameters. It's treated as a stream of N-bit integers
internally. That doesn't mean that M==32, or N==32, or even M==N.
If M != N it means the bytecode load function needs to read in the
bytecode
stream from disk, treat it as a series of M-bit integers that need to be
converted to N-bit ones for native interpretation.
Dan
--------------------------------------"it's like
this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
