Andy Dougherty:
...
# +prompt("And what is sizeof(iv)?", 'ivsize');
# prompt("And your floats?", 'nv');
# +prompt("And what is sizeof(nv)?", 'nvsize');
...
Somehow, this seems like something we ought to be able to do
programmatically. Can't we just compile a quick little C program with
somethin
Andy Dougherty:
# On Wed, 19 Sep 2001, Brent Dax wrote:
#
# > Andy Dougherty:
# > ...
# > # +prompt("And what is sizeof(iv)?", 'ivsize');
# > # prompt("And your floats?", 'nv');
# > # +prompt("And what is sizeof(nv)?", 'nvsize');
# > ...
# >
# > Somehow, this seems like something we ought to be a
On Wed, 19 Sep 2001, Brent Dax wrote:
> Andy Dougherty:
> ...
> # +prompt("And what is sizeof(iv)?", 'ivsize');
> # prompt("And your floats?", 'nv');
> # +prompt("And what is sizeof(nv)?", 'nvsize');
> ...
>
> Somehow, this seems like something we ought to be able to do
> programmatically. Can
At 02:51 PM 9/19/2001 -0400, Andy Dougherty wrote:
>On Wed, 19 Sep 2001, Dan Sugalski wrote:
>
> > At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
>
> > >Of course it doesn't help that perl doesn't have a pack() flag for IV :-).
> >
> > Definitely a pain. :) We need to figure out the size and u
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:5
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
.
"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
>
On Tue, Sep 18, 2001 at 06:47:38PM -0700, Hong Zhang wrote:
>
> 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.
Alignment.
> Hong
>
> > Earlier there was some discussi
ith a long and void* member so that we can cast from a long to a
pointer.
Is that correct?
-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
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;
> } op
Applied.
-Original Message-
From: Simon Cozens
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/18/2001 3:53 PM
Subject: Re: [PATCH] changing IV to opcode_t!!
On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote:
> 8. I would love someone to tes
On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote:
> 8. I would love someone to test it on Tru64 and Win32.
Testing anything on Tru64 is currently impossible, as Jarkko has pointed
out. I'm still trying to wrap my branes around how to fix that. However,
it compiles. I say app
12 matches
Mail list logo
