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
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, 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)
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 dif
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.
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 though
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
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 o
> 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)
We should not rule out 16-bit system completely. It should be possible an
16-bit runtime can easily c
At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
>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
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
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.
>
>
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
-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 wro
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
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
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
On Tue, Sep 18, 2001 at 09:53:23PM +0100, Simon Cozens wrote:
> 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 t
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
27 matches
Mail list logo
