Brent Dax:
# I'll work on it later today.
Patch below sig. I don't know if (or even really think that) this will
apply cleanly--I haven't updated my CVS in a while--but I don't expect
this to go in until after 0.02. This is basically just to show you what
I'm thinking. Let me know if my
On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
+int main(int argc, char **argv) {
+ printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
+ return 0;
+}
$Config{ivsize} not good enough for ya, then? :)
--
You are in a maze of little twisting passages, all alike.
Simon Cozens:
# On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
# +int main(int argc, char **argv) {
# + printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
# + return 0;
# +}
#
# $Config{ivsize} not good enough for ya, then? :)
No, because the user may have chosen a
On Thu, Sep 20, 2001 at 01:57:51AM -0700, Brent Dax wrote:
No, because the user may have chosen a different value for IV. For
Oh, yep, fair enough. That makes sense.
example, I may have chosen 'long long' in Perl 5 but 'long' in Parrot to
be safe (IIRC, we're still having 64-bit issues)
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Andy, I love you and I want to have your children.
--
void russian_roulette(void) { char *target; strcpy(target, bullet); }
On Thu, 20 Sep 2001, Simon Cozens wrote:
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Your job has just begun :-).
Seriously, some serious thought is needed about integral and
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
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
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
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
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
On Wed, Sep 19, 2001 at 12:25:32PM -0400, Dan Sugalski wrote:
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.
I think it's more urgent that we think about having the
At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
On Wed, Sep 19, 2001 at 12:25:32PM -0400, Dan Sugalski wrote:
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.
I think
On Wed, 19 Sep 2001, Dan Sugalski wrote:
At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
I think it's more urgent that we think about having the bytecode written in
native IVs rather than 32 bits; that'll help Tru64 and all the other things
with alignment problems.
Sure. That's a matter
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 use the
appropriate thingie. That should be a mild amount of
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 use the
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't we just
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 able to do
#
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
something
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
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 test it on Tru64
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;
with 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 we are
going
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 discussion about
24 matches
Mail list logo
