At 09:41 PM 9/18/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Ok...let me try to get this straight and I'll repatch...
>
>opcode_t should be something that will represent the native opcode type. In
>most cases it should just be long; however, there might be special systems
>where it is somehting different (int, long long, etc...). IV should be a
>union with a long and void* member so that we can cast from a long to a
>pointer.
>
>Is that correct?
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.
A simple
typedef int opcode_t
is sufficient. Then we just need to have the bytecode loader either mmap or
read or read and translate the bytecode files as appropriate.
"Fixing" Tru64 may be as simple as:
typedef __int32 opcode_t
but I don't know we want to do that. (Though it's perfectly valid in
Dec^WCompaq^HP C)
>-----Original Message-----
>From: Hong Zhang
>To: '[EMAIL PROTECTED]'
>Sent: 9/18/2001 8:47 PM
>Subject: RE: [PATCH] changing IV to opcode_t!!
>
>
>Do we want the opcode to be so complicated? I thought we are
>going to use this kind of thing for generic pointers. The "p"
>member of opcode does not make any sense to me.
>
>Hong
>
> > Earlier there was some discussion about changing typedef long IV
> > to
> > typedef union {
> > IV i;
> > void* p;
> > } opcode_t;
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
