Re: The core platforms list
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 interpreter to be considerd OK. They are:
Linux (x86)
CygWin
Win32
Tru64
OpenVMS (Alpha)
Solaris (Sparc)
FreeBSD (x86)
If a platform's not here it's not because we don't want to run on it,
rather it's because we can't guarantee the manpower to make it right. (If
we can, then new platforms can and will come on board)
So remember, all the world is not *X*, for any value of X you might have...
And, maybe even more important, not all the world has gcc!
in build_interp_starter.pl I find:
--8---
#define DO_OP(w,x,y,z) do { \\
x = (void *)z-opcode_funcs; \\
(void *)y = x[*w]; \\
w = (y)(w,z); \\
} while (0);
EOI
--8---
(cast)foo = bar; syntax is *not* supported in most non-GNU C compilers:
cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I.. -I./include -g -o interpreter.o -c interpreter.c
cc: interpreter.c, line 44: warning 524: Cast (non-lvalue) appears on left-hand side
of assignment.
cc: interpreter.c, line 44: error 1549: Modifiable lvalue required for assignment
operator.
(Almost the same applies to AIX)
Please fix ASAP, so I can send useful test reports ;)
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
AIX 4.2.1 xlc 32threading/non-threading
If that's what it takes to get it on the list.
--
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. Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
--
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. Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: The core platforms list
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.. -I./include -g -o bytecode.o -c bytecode.c cc: bytecode.c, line 53: warning 603: Cast is not lvalue; ++ requires lvalue. cc: bytecode.c, line 53: error 1560: Modifiable lvalue required with operator ++. which comes from #define GRAB_IV(x) *((IV*)*x)++ OK, switching to gcc, just because I'm curious ;) l1:/pro/3gl/CPAN/parrot 149 make test_prog perl make_op_header.pl opcode_table op.h gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o test_main.o -c test_main.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o global_setup.o -c global_setup.c perl build_interp_starter.pl gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o interpreter.o -c interpreter.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o parrot.o -c parrot.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o register.o -c register.c perl process_opfunc.pl basic_opcodes.ops gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o basic_opcodes.o -c basic_opcodes.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o memory.o -c memory.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o bytecode.o -c bytecode.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o string.o -c string.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o strnative.o -c strnative.c gcc -lnsl -lnm -lndbm -lgdbm -ldb -ldld -lm -lc -lndir -lcrypt -lsec -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o l1:/pro/3gl/CPAN/parrot 150 make test perl t/harness Can't open perl script t/harness: No such file or directory make: *** [test] Error 2 l1:/pro/3gl/CPAN/parrot 151 test_prog Warning: Bytecode does not include opcode table fingerprint! l1:/pro/3gl/CPAN/parrot 152 MANIFEST? (using most recent parrot-nightly) -- 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. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: The core platforms list
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 vanished.
Re: The core platforms list
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
Example assembler code (primes.pasm)
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, although Simon's recent article on perl.com was damn good. Leon ps the assembler doesn't grok if I5, NEXT4, NEXT3 or comments on lines which just have labels -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... My name is Inigo Montoya. You killed my father. Prepare to die # Some simple code to print out the primes up to 100 # Leon Brocard [EMAIL PROTECTED] # I1 holds the number we're currently checking for primality set I1, 1 # I2 holds the highest number we want to check for primality set I2, 100 print The primes up to print I2 printare:\n # I1 counts up to I2 REDO: gt I1, I2, OVER, NEXT1 NEXT1: # I3 counts from 2 up to I4 (I1/2) set I3, 2 set I4, 2 div I4, I1, I4 LOOP: gt I3, I4, PRIME, NEXT2 NEXT2: # Check if I3 is a factor of I1 mod I5, I1, I3 if_i_ic I5, NEXT4, NEXT3 NEXT3: # We've found a factor, so it can't be a prime and # we can skip right out of this loop and to the next # number branch NEXT NEXT4: inc I3 branch LOOP PRIME: # We haven't found a factor so it must be a prime print I1 print \n NEXT: # Move on to the next number inc I1 branch REDO OVER: end
Re: The core platforms list
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 (e.g. HFS). I'll probably try building Parrot on Darwin (well, OS X) from time to time, but I don't have the skills (or time) to do much more than notice whether it's broken or not, heh. I hope someone does pick up the Darwin torch, though. I don't want a repeat of the Apache/Perl 5 situation on Darwin (I *still* can't get mod_perl running correctly) -John
RE: The core platforms list
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 Cc: [EMAIL PROTECTED] Sent: 9/19/2001 6:22 AM Subject: Re: The core platforms list 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.. -I./include -g -o bytecode.o -c bytecode.c cc: bytecode.c, line 53: warning 603: Cast is not lvalue; ++ requires lvalue. cc: bytecode.c, line 53: error 1560: Modifiable lvalue required with operator ++. which comes from #define GRAB_IV(x) *((IV*)*x)++ OK, switching to gcc, just because I'm curious ;) l1:/pro/3gl/CPAN/parrot 149 make test_prog perl make_op_header.pl opcode_table op.h gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o test_main.o -c test_main.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o global_setup.o -c global_setup.c perl build_interp_starter.pl gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o interpreter.o -c interpreter.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o parrot.o -c parrot.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o register.o -c register.c perl process_opfunc.pl basic_opcodes.ops gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o basic_opcodes.o -c basic_opcodes.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o memory.o -c memory.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o bytecode.o -c bytecode.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o string.o -c string.c gcc -DDEBUGGING -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I./include -o strnative.o -c strnative.c gcc -lnsl -lnm -lndbm -lgdbm -ldb -ldld -lm -lc -lndir -lcrypt -lsec -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o l1:/pro/3gl/CPAN/parrot 150 make test perl t/harness Can't open perl script t/harness: No such file or directory make: *** [test] Error 2 l1:/pro/3gl/CPAN/parrot 151 test_prog Warning: Bytecode does not include opcode table fingerprint! l1:/pro/3gl/CPAN/parrot 152 MANIFEST? (using most recent parrot-nightly) -- 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. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: The core platforms list
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 beautifully too. This alignment bug is a MAJOR problem and I am going to work on it tonight. Simon -- An algorithm must be seen to be believed. -- D.E. Knuth
Re: The core platforms list
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 AIX 4.2.1 xlc 32threading/non-threading If that's what it takes to get it on the list. The daily reports are cool, but it takes more than those to get on the list. We also need someone who can fix the breakage. Once we have that... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The core platforms list
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...) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The core platforms list
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 only 32-character, case-insensitive names. Unless the Finder is hiding something from me. HFS+ supports 255 character file names. Yes, the (classic Mac OS) Finder is hiding something from you, as are the rest of the classic Mac OS file access APIs, which are limited to 32 characters and weren't updated when HFS+ was introduced with Mac OS 8.1(?). In Darwin and OS X on HFS+, feel free to: touch thisfilenameismuchlongerthanthirtytwocharactersanditworks (HFS and HFS+ are indeed case-insensitive though) -John
Re: The core platforms list
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 useful when we have many more features implemented, and there's a high probability that most features in a snapshot will actually be working (for some value of working)? Perhaps we need to more loudly disclaim parrot-nightly on the website and docs, or maybe even put it on hold until there's more chance it'll be useful? Nat
Re: Example assembler code (primes.pasm)
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 be better. I'd been thinking about registering parrotcode.org or something. although Simon's recent article on perl.com was damn good. Thank you. I wasted a lot of time trying to implement a prime factoring algorithm before realising it couldn't be done with our current range of ops; I forget exactly why. -- I washed a sock. Then I put it in the dryer. When I took it out, it was gone. -- Steven Wright
Re: The core platforms list
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 be working (for some value of working)? That's not what I mean. parrot-nightly was the hastily-hacked up thing I hosted on NetThink; it wasn't an official service. Real snapshots of the CVS *are* available, built every six hours, from http://cvs.perl.org/snapshots/parrot -- They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. -- Carl Sagan
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: t/op/integer.t is IMHO wrong
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 notice that. : If anyone feels like defining a policy on what Parrot does with out-of-range numbers, and what happens on integer overflow, I'll submit patches to the tests to check against it. I'd rather we didn't just modify the tests to never trigger overflow conditions, however; that's just sweeping the issue under the rug. Integer and float ops, *on integer and float registers* do undefined things on over/underflow. No guarantees, no promises, no certainty. Price of speed. What they do with PMCs, though, is another matter. Those will convert or throw interpreter exceptions, as appropriate. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Bytecode safety
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 speed penalty to a minimum. We can use similar model as Java bytecode. Because of poor design, the Java bytecode requires exponential algorithm to verify the bytecode, mainly caused by weak-typing on local variables (where all other parts of Java runtime are strongly typed), and the notorious jsr/ret bytecode. We should avoid the same kind of mistakes. The bytecode verification should be about O(n * ln(n)). Given how weakly typed so much of Perl (and thus Parrot) is, I'm not sure that there's much we can do to verify externally. The best I can think of is to have the dangerous ops validate their parameters and the oploop do resource checks as appropriate. :( I may, however, be suffering from a lack of imagination. That'd be OK. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Check NV alignment for Solaris
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. (I assume NVs are twice the size of ops, but that could be incorrect) 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 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: Check NV alignment for Solaris
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 trip across alignment rules and size
issues. (I assume NVs are twice the size of ops, but that could be incorrect)
Yup, and not just on Solaris. Even on plain old Linux/86, when IV = long
long, and NV = double, then $Config{ivsize} = $Config{nvsize} = 8.
The bleadperl used to Configure and build parrot may well have a default
ivsize of 8 (since the default bleadperl may well be set up for 64-bit
operations).
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: The core platforms list
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 case-folded collision on the HFS+ side is handled by adding \0 bytes until the names are distinct. The finder has a bit of a mess renaming them, but at least you can see them as separate files. And no collisions from the Unix side! So, foo, Foo, and FOO would be stored as foo Foo\0 and FOO\0\0, effectively. Ick. Is there anybody I can write at Apple to beg for this? If you're going to beg, beg for an actual case-sensitive file system, not an evil hack on top of HFS+ (the hard link hacking is bad enough ;) Check lists.apple.com for the relevant mailing list archive(s) to see how this debate has gone so far. Bletch. Case-insensitivity's much nicer in a filesystem. But this isn't the place to go into that, I think. :) 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: The core platforms list
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 32threading/non-threading AIX 4.3.3 vac/gcc 32/64 threading/non-threading AIX 4.2.1 xlc 32threading/non-threading If that's what it takes to get it on the list. The daily reports are cool, but it takes more than those to get on the list. We also need someone who can fix the breakage. Once we have that... :) I cannot promise anything, but when the 'make test' results drip in, one might never know how enthousiatic I might become ;) -- 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. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
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
Quick heads-up on the conditional branch args
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 generally a good thing. I'll update the core parrot stuff and the tests, but I'm leaving the rest alone for the moment. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
HP-UX first test results
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. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org parrot.log.gz
Re: HP-UX first test results
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 programmer.
Re: HP-UX first test results
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. Yes. It looks identical to the problem I reported yesterday. -- 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 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: Check NV alignment for Solaris
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. (I assume NVs are twice the size of ops, but that could be incorrect) I am strongly against embedded any constants (other than 32-bit literals) into opcode stream. Floats format is very platform dependent. We should use constant pool for it. The float literals are 64-bit wide, there is no way to align it correctly. Once we have float embedded in opcode stream, it will very difficult to patch it. There is really no obvious benefit to do so. We should just use constant pool. And leave opcode as signed 32-bit integer stream. The 32-bit value can be represented using different formats in memory or in file -- endian, and size. Hong
Re: HP-UX first test results
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 pack() and IV size. Beware! I just embedded it in my bleadperl smoke, so it'll be tested about 256 times every day as of tonight for the snapshot available at 22:54 local dutch time. -- 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. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
RE: [PATCH] Remove C++ style comment
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 parrot/config_h.in parrot-andy/config_h.in --- parrot/config_h.in Wed Sep 19 11:57:11 2001 +++ parrot-andy/config_h.in Wed Sep 19 12:08:27 2001 @@ -18,7 +18,7 @@ typedef void DPOINTER; typedef void SYNC; -//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC; +/* typedef IV *(*opcode_funcs)(void *, void *) OPFUNC; */ #define FRAMES_PER_CHUNK 16 -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[REPATCH] changing IV to opcode_t
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
niave question about Parrot::Opcode
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 $params[0] =~ /^\d+$/) {
my $count = shift @params;
die $file, line $.: opcode $name parameters don't match count\n
if ($count != @params);
}
#
#
#
}
I realize that the $count inside the if block shown masks the $count
declared outside the while loop, but (to me) this would be easier to
understand if the inner $count where changed to $numParams -- it is more
obvious on casual reading that $count and $count are two different
things. Am I missing something?
2) It also appears that a second (older?) version of read_ops and an
associated pile of pod is still in the Opcode.pm file can this be
trimmed (removing about 80 lines from the file)?
thanks,
-pate
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
64 bit Assembler
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 :)
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
another silly question about Parrot::Opcode
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:
my $numParams = () = grep {/[ni]/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $numParams * 2;
which is (I think) more legible, and (in limited testing) about 30%
faster -- probably not a big deal in something so little used
Is there a reason not to do this?
-pate
RE: another silly question about Parrot::Opcode
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]
Sent: 9/19/2001 2:11 PM
Subject: another silly question about Parrot::Opcode
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:
my $numParams = () = grep {/[ni]/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $numParams * 2;
which is (I think) more legible, and (in limited testing) about 30%
faster -- probably not a big deal in something so little used
Is there a reason not to do this?
-pate
RE: [REPATCH] changing IV to opcode_t
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 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
RE: [PATCH] mem_allocate_aligned explanation
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
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.9
diff -u -r1.9 memory.c
--- memory.c2001/09/16 01:45:51 1.9
+++ memory.c2001/09/18 05:24:28
@@ -14,6 +14,29 @@
/*=for api mem mem_allocate_aligned
Allocate a chunk of memory aligned on a power-of-2 boundary
+
+ This is a boundary for which all the low bits of the address
+ are zeroes. Basically take the size of an object, round it up to a
+ power-of-two size (256, 512, 1024, whatever) and make sure that you
can
+ mask out the low bits with no problem. So for an up to 256-byte
thing the
+ low 8 bits are zero, for a thing that's between 257 and 512 the low
9 bits
+ are zero, and so on.
+
+ The reason for this is nasty, and basically speed. If I'm aligned
properly,
+ and I have an address in the middle of one of my aligned structures,
I can
+ mask the low bits off and find the base of the whole structure
without
+ needing embedded pointers or anything.
+
+ Register frames work like this, for example. The first chunk of the
+ register frame is some meta-information (forward and back pointers,
frames
+ used, and so forth) while the rest is sets of register arrays. If I
have an
+ address of one of the register arrays in the frame (which I do) I
can find
+ the base structure by lopping the low bits off. Cheaper in memory
terms
+ than having lots of back pointers. (Time, too, since I don't have to
fill
+ those back-pointers in)
+
+ It is a hack that might go if it turns out that having the back
pointers is
+ cheaper, though.
*/
void *
mem_allocate_aligned(IV size) {
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: cvs snapshots
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 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 something like cvs update -D some_date echo some_date .timestamp or something like this, to make the checkout reproducible. In perl5 there is the .patch; since cvs does not have aniything like that, I need something to identificate the snapshot the smoke was run against. Thanks! Mattia
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.
Not yet automated Smoke report
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 ? v1.08 on linux using cc version 2.95.2 2313 (Debian GNU/Linux) O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- F F --defaults --define libs=-lm --define iv=int --define nv=double F F --defaults --define libs=-lm --define iv=long --define nv=double | | | +- --debugging +--- normal Failures: linux--defaults --define libs=-lm --define iv=int --define nv=double linux--debugging --defaults --define libs=-lm --define iv=int --define nv=double linux--defaults --define libs=-lm --define iv=long --define nv=double linux--debugging --defaults --define libs=-lm --define iv=long --define nv=double t/op/integerdubious DIED. FAILED test 1
Don't forget the binmodes...
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 even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Don't forget the binmodes...
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 --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Changes to interpreter op table and simplified DO_OP
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 out?
Dan? Does this fly in the face of your overall design, or is this
a good thing?
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
? ;q
? op_info.patch
? t/inc.pasm
? t/jumpoob.pasm
? t/jumpsub.pasm
? t/substr.pasm
? t/jump2.pasm
? t/jump3.pasm
? t/jump4.pasm
? t/runoob.pasm
? t/test.pbc.x
? t/op/integer8.pasm
? t/op/integer8.out
? t/op/integer9.pasm
? t/op/integer9.out
? t/op/integer10.pasm
? t/op/integer10.out
? t/op/integer11.pasm
? t/op/integer11.out
? t/op/integer12.pasm
? t/op/integer12.out
? t/op/integer13.pasm
? t/op/integer13.out
? t/op/integer14.pasm
? t/op/integer14.out
? t/op/integer15.pasm
? t/op/integer15.out
? t/op/integer16.pasm
? t/op/integer16.out
? t/op/integer17.pasm
? t/op/integer17.out
? t/op/integer18.pasm
? t/op/integer18.out
? t/op/integer19.pasm
? t/op/integer19.out
? t/op/integer20.pasm
? t/op/integer20.pbc
? t/op/integer20.out
? t/op/number6.pasm
? t/op/number6.out
? t/op/number7.pasm
? t/op/number7.out
? t/op/number8.pasm
? t/op/number8.out
? t/op/number9.pasm
? t/op/number9.out
? t/op/number10.pasm
? t/op/number10.out
? t/op/number11.pasm
? t/op/number11.out
? t/op/number12.pasm
? t/op/number12.out
? t/op/number13.pasm
? t/op/number13.out
? t/op/number14.pasm
? t/op/number14.out
? t/op/number15.pasm
? t/op/number15.out
? t/op/number16.pasm
? t/op/number16.out
? t/op/number17.pasm
? t/op/number17.out
? t/op/number18.pasm
? t/op/number18.pbc
? t/op/number18.out
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.11
diff -u -r1.11 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/19 20:05:06 1.11
+++ build_interp_starter.pl 2001/09/19 22:20:19
@@ -2,6 +2,9 @@
use strict;
use Parrot::Opcode;
+my %opcodes= Parrot::Opcode::read_ops();
+my $opcode_fingerprint = Parrot::Opcode::fingerprint();
+
open INTERP, include/parrot/interp_guts.h or die Can't open
include/parrot/interp_guts.h, $!/$^E;
print INTERP CONST;
@@ -14,57 +17,35 @@
* Best not edit it
*/
-#define BUILD_TABLE(x) do { \\
+op_info_table_t builtin_op_info_table = {
+/* TODO: (void *) casting here sucks! */
CONST
-my %opcodes= Parrot::Opcode::read_ops();
-my $opcode_fingerprint = Parrot::Opcode::fingerprint();
-
for my $name (sort {$opcodes{$a}{CODE} = $opcodes{$b}{CODE}} keys %opcodes) {
-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};
-
-#
-# BUILD_NAME_TABLE macro:
-#
-
-print INTERP CONST;
-#define BUILD_NAME_TABLE(x) do { \\
-CONST
+if ($opcodes{$name}{ARGS}) {
+ printf INTERP %-18s }, join(, , map { '$_' } @{$opcodes{$name}{TYPES}});
+} else {
+printf INTERP %-18s }, '*';
+}
-for my $name (sort {$opcodes{$a}{CODE} = $opcodes{$b}{CODE}} keys %opcodes) {
-print INTERP \tx[$opcodes{$name}{CODE}] = \$name\; \\\n;
-}
-print INTERP } while (0);\n;
-
-
-#
-# BUILD_ARG_TABLE macro:
-#
-
-print INTERP CONST;
-#define BUILD_ARG_TABLE(x) do { \\
-CONST
-
-for my $name (sort {$opcodes{$a}{CODE} = $opcodes{$b}{CODE}} keys %opcodes) {
-print INTERP \tx[$opcodes{$name}{CODE}] = $opcodes{$name}{ARGS}; \\\n;
+printf INTERP }, /* %4d */\n, $opcodes{$name}{CODE};
}
-print INTERP } while (0);\n;
+print INTERP };\n\n;
#
# Spit out the DO_OP function
#
+# w = code
+# z = interpreter
+#
print INTERP EOI;
-#define DO_OP(w,x,y,z) do { \\
-x = (void *)z-opcode_funcs; \\
-y = (opcode_t* (*)())x[*w]; \\
-w = (y)(w,z); \\
- } while (0);
+#define DO_OP(PC,INTERP) PC = ((INTERP-opcode_info)[*PC].func)(PC,INTERP);
EOI
# Spit out the OPCODE_FINGERPRINT macro
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.18
diff -u -r1.18 interpreter.c
--- interpreter.c 2001/09/19 20:05:06 1.18
+++ interpreter.c 2001/09/19 22:20:19
@@ -13,9 +13,10 @@
#include parrot/parrot.h
#include parrot/interp_guts.h
-char *op_names[2048];
-int op_args[2048];
+/* char *
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
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 confusing. :(
+#define DO_OP(PC,INTERP) PC = ((INTERP-opcode_info)[*PC].func)(PC,INTERP);
I'm highly unconvinced that this is as portable as you'd like to think it is.
+ /* TODO: Why not 'op_info_table_t
opcode_info'? */
Because we want to keep our developers sane.
Simon
--
Rule 3: If the character is comprised of a container without another radical,
then Rule 3 will not apply.
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
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 run for me. Anyone else interested in trying this out? 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. Separate arrays would be fine, but just not unified like that. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cvs snapshots
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 something like cvs update -D some_date echo some_date .timestamp the timestamp of the tar ball should include this, but I've added a .timestamp file anyway. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
changes for new operators
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 long as it consists of a base name followed by some sequence of _type where type is in ( i s n p ic sc nc ). Thanks! Tanton
Darwin - looking good
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 dependency on an updated version of Test::Harness. So I downloaded, built and installed all those. Then I tried the Parrot tests again. Still no joy. I eventually discovered that newer versions of Test::Simple *include* Test::More, and that my installing Test::More had overwritten the _later_ version that was installed when I installed Test::Simple. So I reinstalled Test::Simple, and: [robin@robin parrot]$ make test perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number.ok, 2/23 skipped: various reasons t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok All tests successful, 4 subtests skipped. Files=5, Tests=74, 31 wallclock secs (14.69 cusr + 10.05 csys = 24.74 CPU) which looks okay to me. Are there any plans to remove the dependency of Parrot::Test on non-core modules? It's bound to be a stumbling block for quite a few people, surely? If not, I'll contribute a patch which makes the failure more graceful and informative. .robin.
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
-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, but the output is so much
more readable in the generated file. A good trade-off in my book (my book
allows printf :-)
+#define DO_OP(PC,INTERP) PC = ((INTERP-opcode_info)[*PC].func)(PC,INTERP);
I'm highly unconvinced that this is as portable as you'd like to think it is.
Yeah. I'm not a portability guru. Obviously the meaning is the same to a
human C programmer and we remove the (explicit) temporaries. I think this
is more *redable*, but I can't speek to whether it is equally
*compilable*. I don't see any reason why it wouldn't be, but as I said,
I don't know all there is to know about portability when it comes to stuff
like this. I'm hoping to learn, though, if someone tries it and they tell
me how it barfs.
+ /* TODO: Why not 'op_info_table_t
opcode_info'? */
Because we want to keep our developers sane.
The comment is there because it doesn't compile. I don't know what the
developer sanity effects would be if it did compile.
Regards,
-- Gregor
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
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. Separate arrays would be fine, but just not unified like that. (This may be free software, but them ain't free cycles! :-) Suppose I put back the function-pointers-only array and remove the function pointers from the new one (partway back to the way it was). Do you see other problems with this? Simon had some portability and readability concerns. The former I don't see (but would like to), and the latter I...well...don't see :-) Regards, -- Gregor
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
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 the L1 cache hit rate, and I'd rather not do that. Separate arrays would be fine, but just not unified like that. (This may be free software, but them ain't free cycles! :-) Damn straight. :) Making more work for us is fine if it makes the ultimate interpreter faster. Suppose I put back the function-pointers-only array and remove the function pointers from the new one (partway back to the way it was). Do you see other problems with this? I want the table we look function pointers up in to be *just* function pointers and nothing but. (I'm also considering analyzing the code the compiler spits out and ordering the opcodes such that ones commonly executed together are next to one another in the table) The big reason here is cache coherency, and here's a (simplified) explanation of why it's important. When the CPU fetches data from memory into its cache, it usually fetches a good-sized chunk, (called a cache line) anywhere from 8 to 64 bytes at once depending on the CPU architecture. Getting that data in is reasonably slow, especially if it has to come in from main memory. (We're talking 10 to 100 cycles) Once it's in the cache, though, accessing it takes a cycle or two. Generally speaking a single function table entry will take less than a whole cache line. That means we get the rest of the data in that cache line loaded free, and we don't have to pay to fault it in later. If we have other stuff in the table, though, we're loading in useless data. (Useless in the sense that we're not going to use it) 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) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
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 confusing. :(
It may be a little less clear to read the code, but the output is so much
more readable in the generated file. A good trade-off in my book (my book
allows printf :-)
People will generally be reading the code, not the output in the generated
file. I'd prefer to optimize readability in the core files as opposed to
the generated ones when we have to choose.
+#define DO_OP(PC,INTERP) PC =
((INTERP-opcode_info)[*PC].func)(PC,INTERP);
I'm highly unconvinced that this is as portable as you'd like to think
it is.
Yeah. I'm not a portability guru. Obviously the meaning is the same to a
human C programmer and we remove the (explicit) temporaries. I think this
is more *redable*, but I can't speek to whether it is equally
*compilable*. I don't see any reason why it wouldn't be, but as I said,
I don't know all there is to know about portability when it comes to stuff
like this. I'm hoping to learn, though, if someone tries it and they tell
me how it barfs.
Odds are the temps are irrelevant to the ultimate code speed. Any compiler
worth its salt will optimize them properly, and the ones that suck, well,
there's not much we can do about that. :)
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
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 not Heinlein fans, or they would realize that TANSTAAFL(oad). : Sorry, couldn't resist. Dave
Draft switch for DO_OP() :-)
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
redefining every op as Parrot_op_foo. :-(
so I suggested the enum fields and case be made
something like add_i_op_idx. But certainly other
things are possible.
Heck, I'll attach the diff.
Gibbs and I thought that the build_interp_starter
and process_opfuncs perl files ought to be able
to share more code, particularly since this submission
is practically a copy of process_opfuncs, and the
enum is trivially done inside build_interp_starter.
However, we have not come to any decision on _where_
the shared code should go. Suggestions solicited.
One bug: I can't quite deal gracefully
with the #includes, I just nuke 'em and write them back,
but the multi-line C-comment block at the top of
basic_opcodes.ops is a pain. Eliminating it clobbers
everything with a STRING *
Better regexen solicited...
Let me know what you think.
Cheers.
Michael
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED]printf %d, 0x2a;
-- deep thought
process_switch.pl
--- build_interp_starter.pl.bak Wed Sep 19 20:57:19 2001
+++ build_interp_starter.pl Wed Sep 19 21:42:35 2001
@@ -4,6 +4,7 @@
open INTERP, include/parrot/interp_guts.h or die Can't open
include/parrot/interp_guts.h, $!/$^E;
+
print INTERP CONST;
/*
*
@@ -27,6 +28,30 @@
#
+# Write the enum of opcodes in order
+#
+
+#
+# this is failing when interpreter.c compiles,
+#`Parrot_op_set_i_ic' redeclared as different kind of symbol
+#
+
+print INTERP \n\n;
+print INTERP enum {\n;
+
+my $names =
+ join ,\n,
+ map { \t$_ }
+ sort {$opcodes{$a}{CODE} = $opcodes{$b}{CODE}}
+ keys %opcodes;
+
+print INTERP $names, \n;
+
+print INTERP };\n\n;
+
+
+
+#
# BUILD_NAME_TABLE macro:
#
@@ -54,12 +79,14 @@
print INTERP } while (0);\n;
+
+
+
#
# Spit out the DO_OP function
#
print INTERP EOI;
-
#define DO_OP(w,x,y,z) do { \\
x = (void *)z-opcode_funcs; \\
y = (opcode_t* (*)())x[*w]; \\
Changes to assemble.pl: Includes and Macros
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 filename # End of filename at the beginning and end of the included file. Macros are defined like: println macro thing print thing print \n endm and invoked like println My happy string in the listing, expanded macros appear with in front of the code. You should be able to include up to any depth, but I didn't test it. In addition, macros should be able to use other macros. I did some basic tests, but nothing extensive. The only incompatibility I've introduced is now assemble.pl won't read from stdin...you have to give it a filename. Patches welcome! Enjoy! Brian
RE: question about branching/returning
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 list Sent: 9/20/2001 12:22 AM Subject: question about branching/returning I'm working on documenting the opcodes, and I want to make sure that I understand the 'RETURN' code properly. I've poked around a little bit to see if I coudl figure it out, but I don't want to divert too much. Would someone please explain to me what each of the following does? RETURN 4 RETURN 0 RETURN -2 # Is this even legal? Thanks in advance, Dave
RE: question about branching/returning
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: 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.
Re: Changes to assemble.pl: Includes and Macros
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 could be because the assembler documentation doesn't exist, but... :) -- King's Law of Clues : Common sense is inversely proportional to the academic intelligence of the person concerned.
Re: question about branching/returning
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 op. end *ought* to break the loop. Whoever rewrote the op loop to keep going until the end of the bytecode stream didn't think of that. :) -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Re: question about branching/returning
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 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. end *ought* to break the loop. Whoever rewrote the op loop to keep going until the end of the bytecode stream didn't think of that. :) -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Re: question about branching/returning
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, zero. The end
function itself is probably never called.
But this still sucks:
while (code = code_start code (code_start + code_size) code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should store
code_end = code_start + code_size. And at best...
DS The default dispatch loop shouldn't check. The Safe dispatch loop (note the
DS caps there... :) should check.
--
User: In 1793 the french king was executed.
MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
RE: question about branching/returning
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
To: Dave Storrs
Cc: 'The Perl 6 Internals list '
Sent: 9/20/2001 12:53 AM
Subject: Re: question about branching/returning
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, zero. The
end
function itself is probably never called.
But this still sucks:
while (code = code_start code (code_start + code_size)
code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should
store
code_end = code_start + code_size. And at best...
DS The default dispatch loop shouldn't check. The Safe dispatch loop
(note the
DS caps there... :) should check.
--
User: In 1793 the french king was executed.
MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
Re: The core platforms list
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 John introduced with Mac OS 8.1(?). In Darwin and OS X on HFS+, feel free to: John touch thisfilenameismuchlongerthanthirtytwocharactersanditworks Ooh! cool. I might need to reinstall darwin then. 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 case-folded collision on the HFS+ side is handled by adding \0 bytes until the names are distinct. The finder has a bit of a mess renaming them, but at least you can see them as separate files. And no collisions from the Unix side! So, foo, Foo, and FOO would be stored as foo Foo\0 and FOO\0\0, effectively. Is there anybody I can write at Apple to beg for this? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
