G'day all.
I have a suggestion for allowing parrot implementations to execute
code more efficiently. Add an instruction or other annotation which
denotes what registers are live at some point in the code. The
intended usage is that compilers which wish to generate this
information generate
Andrew J Bromage sent the following bits through the ether:
What do you all think? Leon mentioned control flow graphs a few days
ago, but I think that live value information is more generally useful
to optimising interpreters and JIT compilers.
I guess it depends what level you want to be
On Sun, Sep 23, 2001 at 06:59:48PM -0700, Dave Storrs wrote:
I.e., what is fair game to be worked on
* Documentation
* Tests
* Portability fixes
and what is a hold off for now?
* Everything else
--
I see ADA as a larger threat than communism at this point in time -- Ted Holden
On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
Nope. At the very least, a bytecode file needs to start with:
8-byte word:endianness (magic value 0x123456789abcdef0)
byte: word size
byte[7]:empty
word: major version
word: minor version
Where
On Monday 24 September 2001 03:27, Dan Sugalski wrote:
At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
http://astray.com/mandlebrot.pasm
Leon, you're a sick, sick man.
Okay, I think that means we need to weld in bitmap handling opcodes into
the interpreter. :)
Also looks like there are
Dan Sugalski [EMAIL PROTECTED] wrote:
Subject: What should and shouldn't get documented?
I see there's a lot of embedded documentation going into the core, and
that's a good thing. That brings up a question, though--what exactly should
we document, and where should it be seen?
For an
I wrote:
Should we go the full hog and make the /*=for api ... */ bit in the
src field subsume any info we currently append to embed.pl etc in Perl 5?
s/field/file/
On Fri, 21 Sep 2001, Andy Dougherty wrote:
Apropos, here's what I get on Debian Sparc/Linux (my default perl there
has iv='long long', so that's what we get here too). Note that nearly
everything fails.
Ok, I've done cvs update and things are ever so slightly better. On
Friday, I got
On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote:
I'm afraid I'll have very little time this week to track this down myself.
It's OK; I've found myself a SPARC machine and I'm looking into it.
--
Calm down, it's *only* ones and zeroes.
Some questions about implementation:
which scenarios?:
1. external text-file strings (name=value?) chosen at run-time
2. Parrot build-time embedded strings (language chosen at configure)
Do we want to break the messages into sets, such that 256 is 'fatal', 256
to 511 is 'warning', 512 to 767 is
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
Horribly wasteful of memory, definitely, and the final allocation system
will do things better, but this is OK to start.
So to stop it waste memory, subtract 1 first and add it again
DS == Dan Sugalski [EMAIL PROTECTED] writes:
do we always emit one in
loops?
DS At least one per statement, probably more for things like regexes.
what about complex conditional code? i don't think there is an
easy way to guarantee events are checked with inserted op codes.
We're talking bytecode. That will indeed be a case of huge arrays of
tightly packed integers.
For bytecode, it's not a big problem, certainly not one I'm worried about.
Machines that want 64-bit ints have, likely speaking, more than enough
memory to handle the larger bytecode.
I'm more
I'm just curious, is there a plan for how closures will work in Parrot? I
think that closures are one of the coolest Perl 5 features around (despite
their memory leak issues :-), and I'd hate to see them go away.
- D
[EMAIL PROTECTED]
For the 0.0.2 release, do we want floating point constants in the constant
table, or do we want to change the code to work with inline constants...I
think we can do a simple memcpy to make the inline constants work (instead
of casting and assigning.)
Tanton
Gibbs Tanton - tgibbs sent the following bits through the ether:
For the 0.0.2 release
While we're at it: Simon, what do we need to have ready before
we release the next version?
Leon
--
Leon Brocard.http://www.astray.com/
assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've
done a cvs update -dP and it doesn't get added...what happend to this file?
Tanton
On Mon, Sep 24, 2001 at 03:14:19PM +0100, Leon Brocard wrote:
While we're at it: Simon, what do we need to have ready before
we release the next version?
OK, here's the release roadmap for the near future:
0.0.2 will be released when all tests pass on the core platforms.
0.0.3 will be
On Mon, Sep 24, 2001 at 09:16:34AM -0500, Gibbs Tanton - tgibbs wrote:
assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've
done a cvs update -dP and it doesn't get added...what happend to this file?
You need to rerun Configure.
--
[Bastille Linux] Of course, if we
I have a suggestion for allowing parrot implementations to execute
code more efficiently. Add an instruction or other annotation which
denotes what registers are live at some point in the code. The
Does it have to be in the instruction stream to be useful? Why not just
be part of the
On Mon, 24 Sep 2001, Buggs wrote:
On Monday 24 September 2001 03:27, Dan Sugalski wrote:
At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
http://astray.com/mandlebrot.pasm
Leon, you're a sick, sick man.
Okay, I think that means we need to weld in bitmap handling opcodes into
the
G'day all.
On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote:
Does it have to be in the instruction stream to be useful?
No, of course not. I said instruction because that's how I saw it
implemented last, but that was in a compiler backend, not in a virtual
machine
DS At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
Horribly wasteful of memory, definitely, and the final allocation system
will do things better, but this is OK to start.
So to stop it waste memory, subtract 1 first and add it again later.
DS Nah, it'll still waste
I'm just curious, is there a plan for how closures will work in Parrot? I
think that closures are one of the coolest Perl 5 features around (despite
their memory leak issues :-), and I'd hate to see them go away.
I doubt that there's any limitation. In Java, all they had to do was
supply a
On Mon, 24 Sep 2001, Simon Cozens wrote:
On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote:
I'm afraid I'll have very little time this week to track this down myself.
It's OK; I've found myself a SPARC machine and I'm looking into it.
Thank you.
Some perspective for others
All --
Also looks like there are some bugs in the num register handling that need
fixing. :(
Just forgotten or is there more to it?
I just fixed the dec_n_n opcode, and fixed the assembler's handling of
constants like '0.1', which were being routed through oct().
Regards,
-- Gregor
At 10:36 AM 9/24/2001 -0400, Michael Maraist wrote:
On Mon, 24 Sep 2001, Buggs wrote:
On Monday 24 September 2001 03:27, Dan Sugalski wrote:
At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
http://astray.com/mandlebrot.pasm
Leon, you're a sick, sick man.
Okay, I think that
Leon --
Can someone apply this please?
I just applied this patch a few minutes ago...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy
At 12:17 AM 9/24/2001 -0400, Michael Maraist wrote:
Dan wrote:
For bytecode, it's not a big problem, certainly not one I'm worried about.
Machines that want 64-bit ints have, likely speaking, more than enough
memory to handle the larger bytecode.
That's not the problem. The problem is
At 12:24 PM 9/24/2001 +0200, Bart Lateur wrote:
On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
Nope. At the very least, a bytecode file needs to start with:
8-byte word:endianness (magic value 0x123456789abcdef0)
byte: word size
byte[7]:empty
word:
At 01:16 PM 9/24/2001 +0100, Dave Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Subject: What should and shouldn't get documented?
I see there's a lot of embedded documentation going into the core, and
that's a good thing. That brings up a question, though--what exactly
should
At 09:42 AM 9/24/2001 -0700, Wizard wrote:
Some questions about implementation:
which scenarios?:
1. external text-file strings (name=value?) chosen at run-time
2. Parrot build-time embedded strings (language chosen at configure)
Do we want to break the messages into sets, such that 256 is
Dan Sugalski writes:
Speaking from on high here, bytecode is strictly identifiable as to its
characteristics. It will be as portable as a platform implementer wants it
to be. The only 'required' types of bytecode that need to be read are
32-bit integer (both big and little endian) with
At 09:02 AM 9/24/2001 -0500, David M. Lloyd wrote:
I'm just curious, is there a plan for how closures will work in Parrot?
When we create a PMC for a subroutine, it'll grab onto the scratchpad
that's in effect, and that scratchpad has a link to its parent, and so on.
When the last pointer to a
At 12:36 AM 9/25/2001 +1000, Andrew J Bromage wrote:
G'day all.
On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote:
Does it have to be in the instruction stream to be useful?
No, of course not. I said instruction because that's how I saw it
implemented last, but that was in a
At 10:46 AM 9/24/2001 -0400, Michael Maraist wrote:
Why aren't we just using the perl5 memory manager?
Because it's not what I ultimately want, or what Parrot ultimately needs.
That and it would've been more work than it was worth when Parrot was first
set up. (We don't *do* much, so I didn't
Odds are you'll get per-op event checking if you enable debugging, since
the debugging oploop will really be a generic check event every op loop
that happens to have the pending debugging event bit permanently set.
Dunno whether we want to force this at compile time or consider some way to
then what about a win/win? we could make the event checking style a
compile time option.
Odds are you'll get per-op event checking if you enable debugging, since
the debugging oploop will really be a generic check event every op loop
that happens to have the pending debugging event bit
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it likely
is a major overkill for what we are trying to do.
http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
It might make sense to
is it possible the ops to handle variable number of arguments, what I have
in mind :
print I1,,,N2,\n
This should be done by create array opcode plus print array opcode.
[1, 2, 3, 4, 5]
The create array opcode takes n top of stack (or n of registers)
and create an array out of it. Both
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it likely
is a major overkill for what we are trying to do.
http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
It might make sense
Attached patch makes sure you don't try and use register numbers over
31. That is, this patch allows registers I0-I31 and anything else gets
a: Error (foo.pasm:0): Register 32 out of range (should be
0-31) in 'set_i_ic'
Oh, there's also a comment at end of line patch that has snuck in
Michael Maraist wrote:
But wouldn't that make parrot GPL'd?
Yes, Yes it would.
(cup o' coffee and a sux donut, please.)
Never mind. I'll take a look at the docs and look around some more and see
what other clever ideas we can't use.
Grant M.
is it possible the ops to handle variable number of arguments, what I have
in mind :
print I1,,,N2,\n
This should be done by create array opcode plus print array opcode.
[1, 2, 3, 4, 5]
I have a minor issue with a proliferation of createArray. In perl5 we
used the Stack for just
We could use the bsd gettext though, couldn't we?
--Josh
At 12:49 on 09/24/2001 PDT, Wizard [EMAIL PROTECTED] wrote:
Michael Maraist wrote:
But wouldn't that make parrot GPL'd?
Yes, Yes it would.
(cup o' coffee and a sux donut, please.)
Never mind. I'll take a look at the docs and look
Just curious, do we need a dedicated zero register and sink register?
The zero register always reads zero, and can not be written. The sink
register can not be read, and write to it can be ignored.
I brain-stormed this idea a while ago, and here's what I came up with.
We're not RISC, so we
At 12:27 PM 9/24/2001 -0400, Michael Maraist wrote:
then what about a win/win? we could make the event checking style a
compile time option.
Odds are you'll get per-op event checking if you enable debugging, since
the debugging oploop will really be a generic check event every op loop
At 12:38 PM 9/24/2001 -0400, Michael Maraist wrote:
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it likely
is a major overkill for what we are trying to do.
At 09:39 AM 9/24/2001 -0700, Hong Zhang wrote:
Attached patch makes sure you don't try and use register numbers over
31. That is, this patch allows registers I0-I31 and anything else gets
a: Error (foo.pasm:0): Register 32 out of range (should be
0-31) in 'set_i_ic'
Oh, there's also a
--- Hong Zhang [EMAIL PROTECTED] wrote:
Just curious, do we need a dedicated zero register and
sink register?
The zero register always reads zero, and can not be
written. The sink
register can not be read, and write to it can be ignored.
Those, probably not = we have a real nop, and it
Just curious, do we need a dedicated zero register and sink register?
I've been pondering that one and waffling back and forth. At the moment I
don't think so, since there's no benefit to going with a zero register
over
a zero constant, but that could change tomorrow.
For example, once
DS == Dan Sugalski [EMAIL PROTECTED] writes:
then what about a win/win? we could make the event checking style a
compile time option.
DS Odds are you'll get per-op event checking if you enable debugging,
DS since the debugging oploop will really be a generic check event
DS every op
All --
As I understand it, computer languages differ in their implementation
of the mod() function. I've heard some architectures differ, too, so
that the same language (such as C or Perl) might behave differently on
different machines (I'd be interested to know if this is really true).
On 09/24/01 Michael Maraist wrote:
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it likely
is a major overkill for what we are trying to do.
At 02:25 PM 9/24/2001 -0400, Gregor N. Purdy wrote:
Fortunately, there is a perfectly rational definition of the mod(x,y)
function over the full domains of x and y, and even for x and y that
are not integral. This can be found in the book Concrete Mathematics,
Second Edition by Graham, Knuth and
At 01:03 PM 9/24/2001 -0400, Michael Maraist wrote:
is it possible the ops to handle variable number of arguments, what I
have
in mind :
print I1,,,N2,\n
This should be done by create array opcode plus print array opcode.
[1, 2, 3, 4, 5]
I have a minor issue with a
At 08:42 PM 9/24/2001 +0200, Paolo Molaro wrote:
On 09/24/01 Michael Maraist wrote:
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it
likely
is a major overkill for what we are trying to do.
Just out of interest, what are the tests looking like on IRIX?
mmm...not so good.
- SWM
world:~/src/Perl/parrotuname -a
IRIX64 world 6.2 03131016 IP19
world:~/src/Perl/parrotmake test
perl t/harness
t/op/basic..ok 1/2skip() is UNIMPLEMENTED! at
/home/abhaile/swmcd/perl/lib/s
On Mon, Sep 24, 2001 at 03:16:47PM -0400, Steven W McDougall wrote:
t/op/number.t 255 6528023 144 626.09% 1-23
6/74 subtests failed
Looks like Test::Harness has no brains either.
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefer
On Mon, 24 Sep 2001, Uri Guttman wrote:
then what about a win/win? we could make the event checking style a
compile time option.
DS Odds are you'll get per-op event checking if you enable debugging,
DS since the debugging oploop will really be a generic check event
DS every op
I have a minor issue with a proliferation of createArray. In perl5 we
used the Stack for just about everything minus physically setting @x =
(1,2,3). The creation of a dynamic array is a memory hog.
Less of a hog in many ways than using a stack. Worth the times when it's not.
I don't
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it likely
is a major overkill for what we are trying to do.
http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
It might make
Collect all the P(ok)emons on the Core Platforms
and try to find the secret ways to the None Core Platforms.
Then proceed to level 0.0.2.
--
CORE PLATFORMS
--
===
Linux (x86):
make ok / test ok
===
CygWin
On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
Tru64
make ok / test fails
Can I have some more data on this? Works perfectly here.
--
To downgrade the human mind is bad theology.
- C. K. Chesterton
On Monday 24 September 2001 22:48, Simon Cozens wrote:
On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
Tru64
make ok / test fails
Can I have some more data on this? Works perfectly here.
The machine from Compaq Testdrive.
Compaq Tru64 Unix 5.1(JAVA) ES40 4@667MHz (ev6)
All --
I've created a varargs-ish example by making a new op, print_s_v.
This is pretty rough, and I haven't updated the assembler, but it
seems to work.
I'm attaching a patch, and a test program (pt.pasm).
Enjoy!
-- Gregor
When tests fail for Really Bad reasons, they tend to do something like this:
Got: '
'
Expected: '
ok 1
...
'
It'd be really nice if we could intercept that and give more detail on why
the test failed. Did the assembler compile to a PBC ok? Did the interpreter
segfault? (This is what usually
Yet more fun with testing... patch at bottom, rambling first
noop didn't have a test, ironic yes, but imagine the shame if it didn't work.
Also time and bitwise ops tests. For the bitwise ops I've tried to be
platform nice, these tests merely exercise the ops, rather than anything
else.
BUG:
On Tuesday 25 September 2001 00:00, Simon Cozens wrote:
When tests fail for Really Bad reasons, they tend to do something like
this:
Got: '
'
Expected: '
ok 1
...
'
It'd be really nice if we could intercept that and give more detail on why
the test failed. Did the assembler compile to
On Monday 24 September 2001 11:54 am, Dan Sugalski wrote:
Odds are you'll get per-op event checking if you enable debugging, since
the debugging oploop will really be a generic check event every op loop
that happens to have the pending debugging event bit permanently set.
Dunno whether we
I listened in for a while but no one mentioned
Windows CE as a target. I believe that's becoz no
perl5 on Windows CE?
Can someone advise what needs to be done to port
perl6 to CE (with or without porting perl5 first)?
If I have the prerequisites, I'm willing to help - for fun.
(Though I
On Monday 24 September 2001 22:59, Buggs wrote:
On Monday 24 September 2001 22:48, Simon Cozens wrote:
On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
Tru64
make ok / test fails
Can I have some more data on this? Works perfectly here.
The machine from Compaq Testdrive.
-opcode_t *(*(*opcode_funcs)[2048])(); /* Opcode */
- /* function table */
-STRING_FUNCS *(*(*string_funcs)[64])(); /* String function table */
+opcode_t *(**opcode_funcs)(); /* Opcode function table */
+STRING_FUNCS
Buggs:
# Collect all the P(ok)emons on the Core Platforms
# and try to find the secret ways to the None Core Platforms.
# Then proceed to level 0.0.2.
#
# --
# CORE PLATFORMS
# --
# ===
# Linux (x86):
# make ok / test ok
#
On Tue 25 Sep 2001 06:00, Kenneth YK Young [EMAIL PROTECTED] wrote:
I listened in for a while but no one mentioned
Windows CE as a target. I believe that's becoz no
perl5 on Windows CE?
But there *is* perl5 for WinCE. I've just passed the majority of the base
bleadperl test suite on WinCE
75 matches
Mail list logo
