On Wed 19 Sep 2001 11:15, H.Merijn Brand [EMAIL PROTECTED] wrote:
On Tue 18 Sep 2001 20:43, Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, folks, the following platforms are considered core for the parrot
interpreter. That means we need to run on all of them for any release of
the
On Wed 19 Sep 2001 13:10, H.Merijn Brand [EMAIL PROTECTED] wrote:
And, maybe even more important, not all the world has gcc!
and bytecode.c
l1:/pro/3gl/CPAN/parrot 136 make test_prog
cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FI
LE_OFFSET_BITS=64 -I..
On Wed, Sep 19, 2001 at 01:22:04PM +0200, H. Merijn Brand wrote:
Can't open perl script t/harness: No such file or directory
MANIFEST? (using most recent parrot-nightly)
Don't use parrot-nightly; use the snapshots from cvs.perl.org
--
I don't think so, said Rene Descartes. Just then, he
And, maybe even more important, not all the world has gcc!
Hear, hear.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Attached is a cute prime number printer.
It strikes me that we need a central place to put these things - it'd
really help people get stuck into the lowlevel stuff.
How about an examples/ directory in the CVS tree? Alternatively, I
could set up a learning parrot assembler website of some sort,
On 9/18/01 7:26 PM, Randal L. Schwartz wrote:
I'd suggest you Darwin there to be sure you're thinking about
case-insensitive-32-char filenames
Someone will correct me if I'm wrong, but I don't think Darwin even installs
on file systems that support anything less than 255 character file names
Both of these things were fixed when I converted from IV to opcode_t. (not
that I didn't break other things...)
Since that change was made, how many of the core platforms pass? If we lose
one, I need to revert.
Thanks!
Tanton
-Original Message-
From: H.Merijn Brand
To: Simon Cozens
On Wed, Sep 19, 2001 at 08:57:53AM -0500, Gibbs Tanton - tgibbs wrote:
Both of these things were fixed when I converted from IV to opcode_t. (not
that I didn't break other things...)
Since that change was made, how many of the core platforms pass?
Tru64 builds beautifully, but also segfaults
At 11:15 AM 9/19/2001 +0200, H.Merijn Brand wrote:
If the nightly builds start OK, I could add a daily report for
HP-UX 11.00 HPc/gcc 32/64 threading/non-threading
HP-UX 10.20 HPc 32threading/non-threading
AIX 4.3.3 vac/gcc 32/64 threading/non-threading
At 01:10 PM 9/19/2001 +0200, H.Merijn Brand wrote:
(cast)foo = bar; syntax is *not* supported in most non-GNU C compilers:
My sloppiness, I'll fix anything remaining. (It wasn't done out of any
gcc-centrism--I don't even use gcc much. Just never occurred to me that it
wouldn't work...)
On 9/19/01 10:35 AM, Randal L. Schwartz wrote:
John Someone will correct me if I'm wrong, but I don't think Darwin
John even installs on file systems that support anything less than
John 255 character file names (e.g. HFS).
My HFS+ drive held Darwin for at least a little while, and that's
Simon Cozens writes:
On Wed, Sep 19, 2001 at 01:22:04PM +0200, H. Merijn Brand wrote:
Can't open perl script t/harness: No such file or directory
MANIFEST? (using most recent parrot-nightly)
Don't use parrot-nightly; use the snapshots from cvs.perl.org
So parrot-nightly will only be
On Wed, Sep 19, 2001 at 02:49:58PM +0100, Leon Brocard wrote:
How about an examples/ directory in the CVS tree?
I'd rather we didn't do this; I don't want to clutter up Parrot
with auxilliary stuff.
Alternatively, I
could set up a learning parrot assembler website of some sort,
This would
On Wed, Sep 19, 2001 at 08:44:34AM -0600, Nathan Torkington wrote:
Don't use parrot-nightly; use the snapshots from cvs.perl.org
So parrot-nightly will only be useful when we have many more features
implemented, and there's a high probability that most features in a
snapshot will actually
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
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:56 PM 9/18/2001 -0700, Damien Neil wrote:
On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote:
I think that especting 4294967295 == -1 because they have the same
bit pattern ( on two's complement 32 bit machines ) is wrong
I was wondering how long it would take for someone to
At 06:44 PM 9/18/2001 -0700, Hong Zhang wrote:
Proposed: Parrot should never crash due to malformed bytecode. When
choosing between execution speed and bytecode safety, safety should
always win. Careful op design and possibly a validation pass before
execution will hopefully keep the
One of the things that might be coring solaris is the potential for
embedded floats in the bytecode stream. (The more I think about that the
more I regret it...) The ops do a quick and ugly cast to treat some of the
opcode stream as an NV which may trip across alignment rules and size
issues.
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
On Wed, 19 Sep 2001, Dan Sugalski wrote:
One of the things that might be coring solaris is the potential for
embedded floats in the bytecode stream. (The more I think about that the
more I regret it...) The ops do a quick and ugly cast to treat some of the
opcode stream as an NV which may
At 12:08 PM 9/19/2001 -0400, John Siracusa wrote:
On 9/19/01 11:51 AM, Randal L. Schwartz wrote:
John (HFS and HFS+ are indeed case-insensitive though)
Which they *could* have fixed from the Unix side in the same way that
MachTen did it..., and I wish they would. In MachTen, each
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,
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
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
On Wed 19 Sep 2001 16:43, Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:15 AM 9/19/2001 +0200, H.Merijn Brand wrote:
If the nightly builds start OK, I could add a daily report for
HP-UX 11.00 HPc/gcc 32/64 threading/non-threading
HP-UX 10.20 HPc 32
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
I'm about to hack things up so that all the conditional branch opcodes have
only one destination, the one they take if the condition's matched.
(Otherwise they fall through) This should speed things up a bit, as we'll
have less memory that we need to chew through when running, and density's
HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 629 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro WinCE 2.11.
On Wed, Sep 19, 2001 at 06:37:22PM +0200, H. Merijn Brand wrote:
HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
Wow, that one sucked. Betcha it's a problem with pack() and
IV size.
--
If God had a beard, he'd be a UNIX
On Wed, 19 Sep 2001, Simon Cozens wrote:
On Wed, Sep 19, 2001 at 06:37:22PM +0200, H. Merijn Brand wrote:
HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
Wow, that one sucked. Betcha it's a problem with pack() and
IV size.
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
One of the things that might be coring solaris is the potential for
embedded floats in the bytecode stream. (The more I think about that the
more I regret it...) The ops do a quick and ugly cast to treat some of the
opcode stream as an NV which may trip across alignment rules and size
On Wed 19 Sep 2001 18:53, Simon Cozens [EMAIL PROTECTED] wrote:
On Wed, Sep 19, 2001 at 06:37:22PM +0200, H. Merijn Brand wrote:
HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
Wow, that one sucked. Betcha it's a problem with
Thanks. Applied.
-Original Message-
From: Andy Dougherty
To: [EMAIL PROTECTED]
Sent: 9/19/2001 12:22 PM
Subject: [PATCH] Remove C++ style comment
I'm not sure why this is commented out in the first place, but if we
want to keep it, we need to use C-style comments.
diff -r -u
Ok, this patch changes from the union to a simple type. The type is queried
for at configure time. Brent, if you'll ok the configure stuff I'll go
ahead and apply it.
Thanks!
Tanton
patch.dat
parrot hackers,
I'm not going to pretend to be a wizened hacker, but I've got a couple
of questions about Parrot::Opcode that I hope you could answer.
1) _load looks like:
sub _load {
#
#
#
my $count = 1;
while ($fh) {
#
#
#
if (@params
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
I have updated the Assembler to work better with 64 bit platforms. Now, to
run under a 64 bit platform, just change the 'l' to a 'q' in the pack_type
hash. I think Andy's patch will come closer to automatically choosing the
right type, but that's not my area :)
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
I found one more bit that looks odd to me (again in _load), near the end
of the while loop is this code:
my $num_i = () = grep {/i/} @params;
my $num_n = () = grep {/n/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
which could be reduced to:
Nope, I think you've messed up your math there :)
The current version multiplies the number of numeric types seen by two
(because (unportably) most numbers are twice the size of integers). Yours
does not take that into account.
-Original Message-
From: Pat Eyler
To: [EMAIL PROTECTED]
This has been applied. Please rerun Configure.pl after updating.
Thanks!
Tanton
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED] '
Sent: 9/19/2001 1:15 PM
Subject: [REPATCH] changing IV to opcode_t
Ok, this patch changes from the union to a simple type. The
Thanks. Applied.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/19/2001 3:04 PM
Subject: [PATCH] mem_allocate_aligned explanation
This patch adds Dan Sugalski's explanation to the code.
Index: memory.c
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
On Tue, 18 Sep 2001, H.Merijn Brand wrote:
On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen [EMAIL PROTECTED] wrote:
oops, I forgot to tell anyone. I made CVS export and tar up a
snapshot every 6 hours. It is available at
http://cvs.perl.org/snapshots/parrot/
Any chance on
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
here it is.
I'll release Parrot::Smoke 0.01 tomorrow,
promise.
*PLEASE* - change _read to read in test_main.c
- correct integer.t, test 1
not to test 0x == -1
( that's why we have got all F... )
Regards
Mattia
Automated smoke report for patch ?
The assembler's failing with 0a-0D0A conversions in spots. Could someone
familiar with it go binmode all the output files that we spit bytecode to?
Dan
--it's like this---
Dan Sugalski
At 05:28 PM 9/19/2001 -0400, Dan Sugalski wrote:
The assembler's failing with 0a-0D0A conversions in spots. Could someone
familiar with it go binmode all the output files that we spit bytecode to?
Never mind, I took care of it.
Dan
All --
I wanted to have a unified op func, name, argc and argtype[] member
in the interpreter struct, and that led me to make all the changes
in this patch.
I don't know if I've gone too far, but DO_OP is simpler now, and
things still seem to run for me.
Anyone else interested in trying this
On Wed, Sep 19, 2001 at 06:23:41PM -0400, Gregor N. Purdy wrote:
-print INTERP \tx[$opcodes{$name}{CODE}] = (void*)$name; \\\n;
-}
-print INTERP } while (0);\n;
+printf INTERP { (void *)%-12s, %-14s, %d, { ,
+ $name, \$name\, $opcodes{$name}{ARGS};
This is so much more
At 06:23 PM 9/19/2001 -0400, Gregor N. Purdy wrote:
All --
I wanted to have a unified op func, name, argc and argtype[] member
in the interpreter struct, and that led me to make all the changes
in this patch.
I don't know if I've gone too far, but DO_OP is simpler now, and
things still seem to
On Wed, 19 Sep 2001, Mattia Barbon wrote:
Any chance on rsync? If so, I might set up another smoke suite to bother you
with reports :)
rsync -av cvs.perl.org::parrot-HEAD parrot
For smoking it'll be nice to hace some file with a timestamp of the
checkout, i.e. in the script do
I've updated number.t and integer.t to use the new comparison operators. I
also made a minor patch to opcode_table because the if ops had the wrong
number of args. Finally, I made a change to assemble.pl to grok operators
better. It should now handle an operator no matter how you name it as
I only had one real problem with Parrot on Darwin, which really has
nothing to do with Darwin at all. The first time I tried to make test
I got a slew of errors about Test::More, so I diligently went to CPAN
and downloaded the latest version. It claimed dependency on Test::Simple,
which claimed
-print INTERP \tx[$opcodes{$name}{CODE}] = (void*)$name; \\\n;
-}
-print INTERP } while (0);\n;
+printf INTERP { (void *)%-12s, %-14s, %d, { ,
+ $name, \$name\, $opcodes{$name}{ARGS};
This is so much more confusing. :(
It may be a little less clear to read the code,
Dan? Does this fly in the face of your overall design, or is this
a good thing?
Cool, but not a good thing. The problem with it is there's a lot of
extraneous stuff scattered in the function table structure. That's going to
reduce the L1 cache hit rate, and I'd rather not do that.
At 09:23 PM 9/19/2001 -0400, Gregor N. Purdy wrote:
Dan? Does this fly in the face of your overall design, or is this
a good thing?
Cool, but not a good thing. The problem with it is there's a lot of
extraneous stuff scattered in the function table structure. That's
going to
reduce
At 09:16 PM 9/19/2001 -0400, Gregor N. Purdy wrote:
-print INTERP \tx[$opcodes{$name}{CODE}] = (void*)$name; \\\n;
-}
-print INTERP } while (0);\n;
+printf INTERP { (void *)%-12s, %-14s, %d, { ,
+ $name, \$name\, $opcodes{$name}{ARGS};
This is so much more
On Wed, 19 Sep 2001, Dan Sugalski wrote:
Basically we're getting a free load on most architectures, so we ought to
use it where we can. (And it doesn't hurt us on those architectures where
we don't have it)
1) Does that make us freeloaders?
2) I guess the architecture designers are
please see attached process_switch.pl
notes inside.
Very rough draft, but I think it does write a correct
define ( but I might be clueless ).
On the note of the enum for the case foo:
Made it work, Gibbs has seen patch, but we wanted to
defer to Dan/Simon because op.h has the knack of
Please test this out to make sure I haven't done anything stupid!
The syntax for including another file is:
include 'filename'
or
include filename
The file will be included as-is at that spot. The listing will reflect
that a series of lines was included by printing
# Start of
RETURN causes the program counter to be incremented by that many opcodes.
So RETURN 4 would move forward 4 opcodes and RETURN -2 would move backward 2
opcodes. Basically, it returns a relative offset from the current position.
-Original Message-
From: Dave Storrs
To: The Perl 6 Internals
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It does a 'RETURN 0', which would increment the PC by 0
opcodes...which either counts as an infinite loop or a no-op, and we've
already got a no-op op.
Dave
On Thu, 20 Sep 2001, Gibbs Tanton - tgibbs wrote:
On Wed, Sep 19, 2001 at 11:29:08PM -0500, Brian Wheeler wrote:
The only incompatibility I've introduced is now assemble.pl won't read
from stdin...you have to give it a filename. Patches welcome!
And, of course, these beautiful new features don't appear in the
assembler documentation. This
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It does a 'RETURN 0', which would increment the PC by 0
opcodes...which either counts as an infinite loop or a no-op, and we've
already got a no-op
Well, I'm in the process of fiddling with this stuff anyway...what do you
want me to make it do?
Dave
On Thu, 20 Sep 2001, Simon Cozens wrote:
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It
On Wed, Sep 19, 2001 at 10:47:44PM -0700, Dave Storrs wrote:
Well, I'm in the process of fiddling with this stuff anyway...what do you
want me to make it do?
Oh, sorry, I see what happens. The last test (code-i) is what I would think
of as *code: it tests whether we're sitting on an end op,
First, code-i doesn't exist anymore...it is back to being *code (much more
readable that way :)
Second, we are going to remove those safety checks on that version of runops
if I'm not mistaken, I just don't think anyone's gotten around to it yet.
-Original Message-
From: Simon Cozens
John == John Siracusa [EMAIL PROTECTED] writes:
John HFS+ supports 255 character file names. Yes, the (classic Mac OS) Finder is
John hiding something from you, as are the rest of the classic Mac OS file access
John APIs, which are limited to 32 characters and weren't updated when HFS+ was
72 matches
Mail list logo
