RE: [PATCH] changing IV to opcode_t!!
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 thought process is flawed.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Configure.plTue Sep 18 11:32:06 2001
+++ Configure.plThu Sep 20 01:48:06 2001
@@ -62,6 +62,8 @@
my(%c)=(
iv = ($Config{ivtype}||'long'),
nv = ($Config{nvtype}||'double'),
+ ivsize = undef, #filled in later in
program
+ nvsize = undef, #ditto
cc = $Config{cc},
#ADD C COMPILER FLAGS HERE
ccflags = $Config{ccflags}. -I./include,
@@ -118,6 +120,17 @@
print END;
+Alright, I'm now gonna compile and run a little C program
+to figure some stuff out.
+END
+
+buildfile(test_c);
+system($c{cc} test.c $c{ccflags} -o test$c{exe}) and die Compilation
of test.c unsuccessful;
+@c{qw(ivsize nvsize)}=(`test$c{exe}` =~ m{(\d+)/(\d+)});
+unlink('test$c{exe}', 'test.c');
+
+print END;
+
Okay, that's finished. I'm now going to write your very
own Makefile, config.h, and Parrot::Config to disk.
END
--- ..\..\parrot-cvs\parrot\config_h.in Fri Sep 14 09:40:36 2001
+++ config_h.in Thu Sep 20 01:44:36 2001
@@ -6,8 +6,12 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
+
typedef ${iv} IV;
+#define ivsize ${ivsize}
+
typedef ${nv} NV;
+#define nvsize ${nvsize}
typedef struct _vtable VTABLE;
typedef void DPOINTER;
@@ -24,7 +28,6 @@
#define MASK_CHUNK_LOW_BITS 0xf000
-
${headers}
--- /dev/null Wed Dec 31 16:00:00 1969
+++ test_c.in Thu Sep 20 01:31:36 2001
@@ -0,0 +1,6 @@
+#include stdio.h
+
+int main(int argc, char **argv) {
+ printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
+ return 0;
+}
Re: [PATCH] changing IV to opcode_t!!
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.
RE: [PATCH] changing IV to opcode_t!!
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 different value for IV. For
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). Thus, we can't depend
on $Config{ivsize}. Thus, a little bit of C is necessary to check for
us. Thus, I am very tired, since I'm talking like this. I should go to
sleep. Goodnight.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Re: [PATCH] changing IV to opcode_t!!
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) Yeah. That needs fixed. :( Thus, I am very tired, since I'm talking like this. I should go to sleep. Goodnight. Sleep well. -- He was a modest, good-humored boy. It was Oxford that made him insufferable.
Re: [PATCH] changing IV to opcode_t!!
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); }
Re: [PATCH] changing IV to opcode_t!!
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 pointer types. Perl currently uses just one type, the IV, for everything. That's both good and bad. Parrot may or may not want to do the same. It may be sensible to have an opcode_t type that is usually 'int' (perhaps 32-bit, perhaps 64, whatever is more natural on the platform), and a separate IV type (quite possibly 64-bit if the platform supports it reasonably well) that holds integer 'data'. I really don't know which is best. Similarly, whatever integral types are used, it would be best to spell out carefully what assumptions we want to make about conversions between pointers and integers. Have the appropriate amount of fun, Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: [PATCH] changing IV to opcode_t!!
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
Re: [PATCH] changing IV to opcode_t!!
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.
Earlier there was some discussion about changing typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
Oh, I see the nub of the problem; no, this is fixing the wrong thing.
The idea was that an IV would be a union of a long (or similar) and a
pointer.
--
I did write and prove correct a 20-line program in January, but I made
the mistake of testing it on our VAX and it had an error, which two
weeks of searching didn't uncover, so there went one publication out the
window. - David Gries, 1980
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
RE: [PATCH] changing IV to opcode_t!!
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, 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
RE: [PATCH] changing IV to opcode_t!!
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
Re: [PATCH] changing IV to opcode_t!!
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 bytecode written in native IVs rather than 32 bits; that'll help Tru64 and all the other things with alignment problems. -- I used to be disgusted, now I find I'm just amused. -- Elvis Costello
Re: [PATCH] changing IV to opcode_t!!
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 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 of getting assemble.pl using the right size for the chosen IV. Configure.pl probably ought to handle that somewhere. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] changing IV to opcode_t!!
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 of getting assemble.pl using the right size for the chosen IV. Configure.pl probably ought to handle that somewhere. Of course it doesn't help that perl doesn't have a pack() flag for IV :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: [PATCH] changing IV to opcode_t!!
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 fun... :)
This might help a bit.
diff -r -u parrot/Configure.pl parrot-andy/Configure.pl
--- parrot/Configure.pl Tue Sep 18 14:05:48 2001
+++ parrot-andy/Configure.plWed Sep 19 14:36:21 2001
@@ -61,7 +61,10 @@
#XXX Figure out better defaults
my(%c)=(
iv = ($Config{ivtype}||'long'),
+ ivsize = ($Config{ivsize}||'4'),
+ longsize = ($Config{longsize}||'4'),
nv = ($Config{nvtype}||'double'),
+ nvsize = ($Config{nvsize}||'8'),
cc = $Config{cc},
#ADD C COMPILER FLAGS HERE
ccflags = $Config{ccflags}. -I./include,
@@ -96,7 +99,9 @@
prompt(What flags would you like passed to your C compiler?, 'ccflags');
prompt(Which libraries would you like your C compiler to include?, 'libs');
prompt(How big would you like integers to be?, 'iv');
+prompt(And what is sizeof(iv)?, 'ivsize');
prompt(And your floats?, 'nv');
+prompt(And what is sizeof(nv)?, 'nvsize');
unless( $c{debugging} ) {
$c{ld_debug} = ' ';
diff -r -u parrot/assemble.pl parrot-andy/assemble.pl
--- parrot/assemble.pl Mon Sep 17 20:32:15 2001
+++ parrot-andy/assemble.pl Wed Sep 19 14:44:49 2001
@@ -7,6 +7,7 @@
use strict;
use Getopt::Long;
use Parrot::Opcode;
+use Parrot::Config;
my %options;
GetOptions(\%options,('checksyntax',
@@ -44,8 +45,21 @@
exit;
}
-# define data types
-my(%pack_type)=('i'='l','n'='d');
+# define data types for pack.
+my %pack_type;
+# Alas perl5.7.2 doesn't have an IV flag for pack().
+if ($PConfig{ivsize} == $PConfig{longsize}) {
+%pack_type = ('i'='l!','n'='d');
+}
+elsif ($PConfig{ivsize} == 8) {
+%pack_type = ('i'='q','n'='d');
+}
+elsif ($PConfig{ivsize} == 4) {
+%pack_type = ('i'='l','n'='d');
+}
+else {
+die(I don't know how to pack an IV!\n);
+}
my(%real_type)=('I'='i','i'='i',
'N'='i','n'='n',
'S'='i','s'='i',
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: [PATCH] changing IV to opcode_t!!
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 appropriate thingie. That should be a mild amount of fun... :) This might help a bit. Keen, if someone could check that in, it'd be great. Want repository privs? (And, y'know, have you ever considered holding a pumpkin ;-) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [PATCH] changing IV to opcode_t!!
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 compile a quick little C program with
something like:
printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
in it, and then parse the output? I don't like asking users stuff like
their int sizes--too prone to confusion and mistyping.
Oh, sure, though I wouldn't worry too much about current Parrot users
being unable to handle such things -- for the most part it'll pick them up
correctly from the Configure defaults from the perl5 being used to build
Parrot. (If run as part of an automated smoke test, for example, we'll
possibly pick up all sorts of 32/64 permutations.)
However, you're right. The Configure mechanism ought to be able to
compile and run a small program. The interface for doing that ought to be
set up before too much effort is made splicing it in ad-hoc. Having
someone else do that hard work has been one of my main goals :-).
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
RE: [PATCH] changing IV to opcode_t!!
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
# programmatically. Can't we just compile a quick little C
# program with
# something like:
#
# printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
#
# in it, and then parse the output? I don't like asking
# users stuff like
# their int sizes--too prone to confusion and mistyping.
#
# Oh, sure, though I wouldn't worry too much about current
# Parrot users
# being unable to handle such things -- for the most part it'll
Hey, even the best programmer can accidentally hit 7 instead of 4 (see
your numeric pad). We should ask as little as possible (without losing
flexibility), and infer everything else.
# pick them up
# correctly from the Configure defaults from the perl5 being
# used to build
# Parrot. (If run as part of an automated smoke test, for
# example, we'll
# possibly pick up all sorts of 32/64 permutations.)
#
# However, you're right. The Configure mechanism ought to be able to
# compile and run a small program. The interface for doing
# that ought to be
# set up before too much effort is made splicing it in ad-hoc. Having
# someone else do that hard work has been one of my main goals :-).
I'll work on it later today.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] changing IV to opcode_t!!
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 like:
printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
in it, and then parse the output? I don't like asking users stuff like
their int sizes--too prone to confusion and mistyping.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
[PATCH] changing IV to opcode_t!!
Earlier there was some discussion about changing
typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
This patch does that. I have tested it on cygwin, solaris 5.8, and solaris
8. I would love someone to test it on Tru64 and Win32.
If this is NO LONGER WANTED, just let me know.
Thanks!
Tanton
patch.dat
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 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 apply it. Incidentally, Parrot's now compiling on Tru64 a lot more cleanly that it's ever done. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
RE: [PATCH] changing IV to opcode_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 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 apply it. Incidentally, Parrot's now compiling on Tru64 a lot more cleanly that it's ever done. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
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;
RE: [PATCH] changing IV to opcode_t!!
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?
-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;
Re: [PATCH] changing IV to opcode_t!!
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 changing typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
