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
