At 11:19 AM 9/19/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Ok, after class I will fix and repatch. Making opcode_t a simple type that
>is configurable.
Cool. If I get a chance (or someone else does) I'll see about hacking the
byteloader to translate to native format if handed a non-native but still
known set of bytecode.
>-----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
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
