I'm freezing imcc as version 1 except for bug fixes.
I'm working on fixing the PCC code emitter before
freezing it.
Besides the bugs concerning non-scalability of the register
allocator, I'm interested in any bug reports (for IMCC only) that may
have been Warnocked until now.
I'd like to get imcc1
Jeff Clites [EMAIL PROTECTED] wrote:
[ threaded var access: read - load - use ... ]
In any case, I thought this sounded like an interesting model,
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the
branch imcc1final, which switched the whole tree to use that sticky
tag. Into which branch
Melvin Smith [EMAIL PROTECTED] wrote:
For some reason 1 test in pcc.t is failing (the nci call)
Off by one error caused by:
-for (j = 0; j 4; j++) {
+for (set = 0; set REGSET_MAX; set++) {
As most loops inside Parrot use the former scheme, I'd rather keep it
# New Ticket Created by Matt Fowles
# Please include the string: [perl #24913]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24913
All~
This patch is similar in concept to the first one I sent; however, it is
Hello
When running this I would expect the 2 files to
look the same, but they don't.
CODE
new P0, .PerlArray # PMC creation
set I10, 1 # wanted numbers. this fails, 1000 works
set P0, I10# set array size
set P0[0], 2 #
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello
When running this I would expect the 2 files to
look the same, but they don't.
Very likely a bug in the buffering code:
$ cmp a_file b_file
a_file b_file differ: char 8192, line 84
and
# define PIO_BLKSIZE 8192
/Stefan
leo
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello
When running this I would expect the 2 files to
look the same, but they don't.
Additionally to the reported bug these seem to be broken:
1) Turning off buffering:
open P1, S0
find_method P10, P1, setbuf
set P5, P1
At 11:20 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
For some reason 1 test in pcc.t is failing (the nci call)
Off by one error caused by:
-for (j = 0; j 4; j++) {
+for (set = 0; set REGSET_MAX; set++) {
As most loops
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the branch
I would not checkout the branch into
At 10:28 AM 1/15/2004 +, you wrote:
On Thu, Jan 15, 2004 at 02:21:56AM -0500, Melvin Smith wrote:
I'd like to get imcc1 working as correct as possible and frozen
within a couple of weeks, then I'll start on the really major rework
for imcc2 (including all the deprecation that is going to
At 1:46 PM -0500 1/13/04, Melvin Smith wrote:
At 11:18 PM 1/12/2004 -0500, Michal Wallace wrote:
On Mon, 12 Jan 2004, Luke Palmer wrote:
A continuation is one snapshot -- it never changes, it never runs.
To invoke the continuation is to take you back to that snapshot and
start running from
At 3:56 PM + 1/13/04, Tim Bunce wrote:
On Tue, Jan 13, 2004 at 10:01:32AM +0100, Leopold Toetsch wrote:
Michal Wallace [EMAIL PROTECTED] wrote:
Here's my guess:
[lots of good stuff from leo]
Is there a Parrot Architecture Overview document that summarises
this kind of high-level view
From: Melvin Smith [EMAIL PROTECTED]
I'd like to get imcc1 working as correct as possible and frozen
within a couple of weeks, then I'll start on the really major rework
for imcc2 (including all the deprecation that is going to make everyone
mad at me.) ;)
Any chance of a list of what is
The NCI interface slings these around and uses them to wrap things
returned from external functions. They're handy things, but they're
also opaque -- there's no good way to directly build up structs to
pass into functions, and there's no good way to retrieve the data
from the bits of the
At 04:17 PM 1/15/2004 +, Jonathan Worthington wrote:
From: Melvin Smith [EMAIL PROTECTED]
I'd like to get imcc1 working as correct as possible and frozen
within a couple of weeks, then I'll start on the really major rework
for imcc2 (including all the deprecation that is going to make
Dan Sugalski [EMAIL PROTECTED] wrote:
If that's living in an managedstruct, then accessing the struct
elements should be as simple as:
set I0, P20['bar']
set S1, P20['plugh']
set P20['baz'], 15
That's mostly done, except for named keys (I used arrays). If you like
named keys,
Okay, since folks are diving into IMCC (assuming we can keep a fight
from breaking out) it's time to address bytecode loading.
We've got the need to have subs that get executed when a code segment
is loaded, a need to have a 'main' sub that gets executed as mainline
code, and subs that get
At 11:07 AM +0100 1/13/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
[ stack layout ]
I'd rather not have the store statically inside the hunk:
- small objects code currently has an upper limit for sized header pools
Doesn't mean we have to use them, honestly. A separate
Folks,
I got reminded the other day that we have a full, working RT
installation (as everyone's probably noticed with the tickets that
fly past on occasion) and, well, we ought to use it. What I'm going
to start doing is putting in tickets for the tasks that need doing,
that way they don't
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Here are some notes on namespaces, picking up a thread from about a month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opcodes. If we're going hierarchic, and we want to
At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the
branch imcc1final, which switched the whole
At 6:16 PM +0100 1/15/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
If that's living in an managedstruct, then accessing the struct
elements should be as simple as:
set I0, P20['bar']
set S1, P20['plugh']
set P20['baz'], 15
That's mostly done, except for named
At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote:
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out
At 1:17 PM -0500 1/15/04, Melvin Smith wrote:
At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote:
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit
At 01:08 PM 1/15/2004 -0500, Dan Sugalski wrote:
At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
Could you be a bit more verbose about that. I've now checked out the
branch imcc1final, which switched the whole tree to
-Original Message-
From: Jeff Clites [mailto:[EMAIL PROTECTED]
Sent: Thursday January 15, 2004 01:28
To: Gordon Henriksen
Cc: [EMAIL PROTECTED]
Subject: Re: JVM as a threading example (threads proposal)
On Jan 12, 2004, at 10:03 AM, Gordon Henriksen wrote:
On Monday,
And now for something reasonably trivial...
I'm going to start in on Parrot's COBOLish chunks, in this case
numeric formatting.
Now, I'm already painfully aware of some of the locale issues that
are involved in formatting numbers and money. (What's the currency
symbol, what's the decimal
Is this relevant?
http://oss.software.ibm.com/icu/userguide/formatNumbers.html
I'm still not clear in my mind what the plan is with regard to ICU. Is
it intended eventually to be:
a) an always-there part of parrot, or
b) just a sometimes-there thing that gets linked in if you mess with
At 8:31 PM +0100 1/15/04, Michael Scott wrote:
Is this relevant? http://oss.software.ibm.com/icu/userguide/formatNumbers.html
I'm still not clear in my mind what the plan is with regard to ICU.
Is it intended eventually to be:
a) an always-there part of parrot, or
b) just a sometimes-there
Now, assuming there's still anyone left reading this message...
We've been threatening to build ICU into parrot, and it's time for
that to start happening. Unfortunately there's a problem--it doesn't
work right now. So, what we need is some brave soul to track ICU
development and keep us
While sitting on IRC with Dan and Jonathan discussing how to
optimizer a certain construct with how we handle globals/package
variables, etc. I came to the conclusion that it would be valuable
to not have to fetch each and every global, lexical or package
variable by name, individually, but
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done at compile / load time of course. If it were all
constants,
Dan Sugalski [EMAIL PROTECTED] wrote:
Unifying the user and control stacks make sense. I don't see any
point in unifying the pad stack with anything, since it's not really
a stack as such, or at least ought not be, and it's got a more
complex linking structure anyway.
Sorry for the unclear
Well I did originally have this in mind, but the more I looked into it
the more I thought it needed someone with unicode experience.
It seems to me that the unicode world is full of ah but in North
Icelandic Yiddish aleph is considered to be an infinitely composite
character and other such
At 10:34 PM +0100 1/15/04, Michael Scott wrote:
Well I did originally have this in mind, but the more I looked into
it the more I thought it needed someone with unicode experience.
It seems to me that the unicode world is full of ah but in North
Icelandic Yiddish aleph is considered to be an
At 2:39 PM -0500 1/15/04, Dan Sugalski wrote:
At 8:31 PM +0100 1/15/04, Michael Scott wrote:
Is this relevant?
http://oss.software.ibm.com/icu/userguide/formatNumbers.html
I'm still not clear in my mind what the plan is with regard to ICU.
Is it intended eventually to be:
a) an always-there
Dan Sugalski wrote:
Folks,
I got reminded the other day that we have a full, working RT
installation (as everyone's probably noticed with the tickets that fly
past on occasion) and, well, we ought to use it. What I'm going to start
doing is putting in tickets for the tasks that need doing,
On Thu, Jan 15, 2004 at 12:45:16PM -0500, Dan Sugalski wrote:
What I'd like is for a volunteer or two to manage the todo queue.
Nothing fancy, just be there to assign todo list items to the folks
that volunteer, make sure they're closed out when done, and reassign
them if whoever's
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and pointers seems to rely on the architecture but is of course
reasonable.
You
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
all the pod errors and done a rudimentary html tree. The state of
parrot pod can be seen here
http://homepage.mac.com/michael_scott/Parrot/docs/html/. That's every
file that has pod in it. Obviously there are a few files such
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done at
At 18:13 -0500 1/15/04, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
It might also be more useful to have it more granular than
16, maybe in 4s or 8s. By doing life analysis and some
weighting, IMCC might be able to turn
On Thu, 2004-01-15 at 15:02, Michael Scott wrote:
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
all the pod errors and done a rudimentary html tree.
Do you have patches to fix the errors in CVS or are they even necessary?
-- c
Melvin Smith writes:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
Why am I thinking of the register keyword in C?
I have no idea and I can't see the relationship. :)
With Parrot's architecture, we have overhead of storing and retrieving
globals, lexicals and package variables
- Original Message -
From: Dan Sugalski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 15, 2004 8:09 PM
Subject: Unicode, internationalization, C++, and ICU
Now, assuming there's still anyone left reading this message...
We've been threatening to build ICU into
At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
Comments questions welcome.
Why am I thinking of the register keyword in C?
I have no idea and I can't see the relationship. :)
I just realized my
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
Melvin Smith writes:
My email was concerned with storing/retrieving multiple variables
with a single lookup, not with hinting to the compiler.
Okay. Can you show an example of this optimization. I'd rather see it
in a HLL talking about PIR, as
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Short version: I was originally going to argue for fully hierarchical
namespaces, identified as above, but after turning this over in my
head for a while, I came to the conclusion that namespaces are not
conceptually
On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
I tried that as well, it spits out identical PASM each time but on the
odd occasion I need to use CTRL-C to get back to the shell.
I'm seeing the same thing on Linux PPC -- odd hangs from time to time
when running PIR, while running the PASM
50 matches
Mail list logo
