Dan Sugalski [EMAIL PROTECTED] wrote:
I think it may be a handy thing if someone'd go through and draw up a
set of rules for the use of temps, and things that'll cause the
register coloring algorithm to go mad. (I'd like to avoid 30 minute
compile sessions--it's a tad tedious :)
Are you
Parrot_reallocate_string was missing one important feature - it did
never reallocate the string. It always allocated a new string and copied
data.
Execution of the test program below goes from 14s to 0.09 s (unoptimized
build, Athlon 800).
leo
_main:
set S0,
set I0, 10
time
WOOLLEY kj (via RT) wrote:
Just a simple set of code cleanups, and moving (mostly headers) to
PDD07 conformance (mostly guard statements).
Thanks, applied.
leo
WOOLLEY kj (via RT) wrote:
Just a simple set of code cleanups, and moving (mostly headers) to
PDD07 conformance (mostly guard statements).
Thanks, applied.
leo
On Apr 21, 2004, at 7:33 PM, Dan Sugalski wrote:
At 11:17 AM -0700 4/21/04, Jeff Clites wrote:
On Apr 21, 2004, at 10:20 AM, Dan Sugalski wrote:
Just to make sure... we're making sure the strings are always
properly decomposed before comparing, right?
Nope, this is a literal equal
Dan Sugalski wrote:
... (I'd like to avoid 30 minute compile
sessions--it's a tad tedious :)
Should be faster now by some factor.
How many symbols are in the biggest compilation unit (parrot -v
registers in .imc)?
leo
On 21 Apr 2004, at 15:14, Dan Sugalski wrote:
I've got a Cunning Plan, oddly enough, though the margins of this
e-mail are too small to contain it. As soon as I get it finished I'm
going to pass it onto the list and to a few non-list folks who I know
are deep into this stuff (Autrijus and Dan
On 21 Apr 2004, at 16:54, Dan Sugalski wrote:
Woohoo! Cool, and thanks very much.
No problem. I can't find someone to come on-board yet, but I did get
an answer to your question.
If he's up for it, could you ask him a question? Namely Treating all
text as Unicode--good idea or bad idea? If
Hello folks,
This will be of interest to only a few people, but it will be good to
have it in the archives for when we need it.
Here is a list of Korean character sets that represent hangul (Korean
symbols) and hanja (Sino-Korean):
- EUC-KR (KSC 5601, renamed to KS X 1001) or Microsoft's
At 1:22 PM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
... (I'd like to avoid 30 minute compile sessions--it's a tad tedious :)
Should be faster now by some factor.
Cool, thanks. I've an optimized build of parrot going now, and I'll
see what things look like when it's dine.
How
At 7:55 AM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
I think it may be a handy thing if someone'd go through and draw up a
set of rules for the use of temps, and things that'll cause the
register coloring algorithm to go mad. (I'd like to avoid 30 minute
Dan Sugalski wrote:
As I sit here and wait for parrot to churn on the output from compiling
a relatively small program
I've put in another factor ~2.5 change for a unit with 2000 temps.
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
Dunno what parrot thinks--it's not done yet. grep says 569 .locals
and 473 temp PMC registers.
I've now enabled some more code that speeds up temp allocation more
(~2.5 for 2000 temps in a unit). This needs that the usage range is
limited to 10 lines. If
On Wed, 2004-04-21 at 13:51, Larry Wall wrote:
In any event, it is absolutely my intent that the builtin array
types of Perl 6 support PDL directly, both in terms of efficiency
and flexibility. You ain't seen Apocalypse 9 yet, but that's what
it's all about. Straight from my rfc list file:
A good register allocation algorithm will always have problems with
big subs, there is nothing that we can do about it.
I think that what real compilers do to solve this problem is
implement two different algorithms: one for normal subs which tries
to generate optimal code, and a naive one
Ok, so I got to thinking about Parrot and compilation last night. Then
something occurred to me, and I'm not sure how it works.
When Perl sees:
class Joe { my $.a; method b {...} }
my Joe $j;
Many things happen and some of them will require knowing what the result
of the
At 4:03 PM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Dunno what parrot thinks--it's not done yet. grep says 569 .locals
and 473 temp PMC registers.
I've now enabled some more code that speeds up temp allocation more
(~2.5 for 2000 temps in a unit). This needs
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
Ok, so I got to thinking about Parrot and compilation last night. Then
something occurred to me, and I'm not sure how it works.
When Perl sees:
class Joe { my $.a; method b {...} }
my Joe $j;
Many things happen and some of them will
At 6:03 PM -0600 4/21/04, kj wrote:
Hello folks,
This will be of interest to only a few people, but it will be good
to have it in the archives for when we need it.
Here is a list of Korean character sets that represent hangul
(Korean symbols) and hanja (Sino-Korean):
- EUC-KR (KSC 5601,
On Apr 21, 2004, at 4:52 PM, kj wrote:
- there are (of course) some character sets that don't work well with
Unicode -- for example, Big5HKSCS doesn't encode in UCS2 (though I
didn't find out why)
UCS-2 is limited--it can only address the BMP (that is, only 2^16
characters). It has been
If I use a C++ compiler to include embed.h:
In file included from /Users/nick/Ponie/ponie06/parrot/include/parrot/embed.h:19,
from perl.h:31,
from miniperlmain.c:27:
/Users/nick/Ponie/ponie06/parrot/include/parrot/interpreter.h:59: error: conflicting
types for
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I do
know it is a legacy charset, but I don't know how much it is still
used. Technically, ASCII is legacy, too. :)
Ah, at this point Unicode's
Nicholas Clark wrote:
Pain being due to these two:
struct Parrot_Interp;
typedef struct Parrot_Interp *Parrot_Interp;
This doesn't seem right.
It is and it isn't. The naming conventions say that struct
Parrot_Interp should really be struct parrot_interp_t, but that's a
ginormous global
At 8:51 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I
do know it is a legacy charset, but I don't know how much it is
still used. Technically, ASCII is
Dan Sugalski [EMAIL PROTECTED] wrote:
registers needed:I43, N0, S12, P3327
registers in .pasm: I25, N0, S20, P32 - 464 spilled
2007 basic_blocks, 2079 edges
Ouch. Register allocation is spending huge times during spilling.
Something is definetely wrong
Dan == Dan Sugalski [EMAIL PROTECTED] writes:
More to the point, Perl 6's compiler will have to parse class Joe,
create a new object of type Class, parse and execute the following
block/closure in class MetaClass, assign the result into the new Class
object named Joe and then continue
On Thu, Apr 22, 2004 at 10:48:51AM -0400, Aaron Sherman wrote:
: 1. Have a feedback loop between Parrot and Perl 6 that allows the
: compiler to execute a chunk of bytecode, get the result as a PMC
: and store it for future use. This will probably be needed
:
Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
lives, nobody's got much standing to call a character set Legacy :)
I suggest Parrot's native character set to be cuneiform.
At 6:04 PM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
registers needed:I43, N0, S12, P3327
registers in .pasm: I25, N0, S20, P32 - 464 spilled
2007 basic_blocks, 2079 edges
Ouch. Register allocation is spending huge times
On Apr 22, 2004, at 9:01 AM, Dan Sugalski wrote:
At 8:51 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I
do know it is a legacy charset, but I don't know
On Thu, Apr 22, 2004 at 11:22:32AM -0400, Dan Sugalski wrote:
: Erm... no. Not even close, really. There's really nothing at all
: special about this--it's a very standard user-defined type issue,
: dead-common compiler stuff. You could, if you wanted, really
: complicate it, but there's no
On Thu, Apr 22, 2004 at 10:29:39AM -0400, Aaron Sherman wrote:
: That said, I now see why hyper goes in Parrot... maybe. It depends on
: how dynamic Perl is about lazy arrays (e.g. my int @foo = 1..Inf)
As dynamic as it needs to be. The built-in array type has to know how
much of the array is
At 9:20 AM -0700 4/22/04, Larry Wall wrote:
On Thu, Apr 22, 2004 at 11:22:32AM -0400, Dan Sugalski wrote:
: Erm... no. Not even close, really. There's really nothing at all
: special about this--it's a very standard user-defined type issue,
: dead-common compiler stuff. You could, if you wanted,
On Thu, Apr 22, 2004 at 12:42:49PM -0400, Dan Sugalski wrote:
: But that's completely irrelevant to the original question, about
: lexical variable classes. I presume you've got a point you're making?
Yes, my point is you didn't actually answer his question.
Larry
On Thu, 2004-04-22 at 11:22, Dan Sugalski wrote:
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
More to the point, Perl 6's compiler will have to parse class Joe,
create a new object of type Class, parse and execute the following
block/closure in class MetaClass, assign the result into the
On Thu, 2004-04-22 at 09:17, Jarkko Hietaniemi wrote:
Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
lives, nobody's got much standing to call a character set Legacy :)
I suggest Parrot's native character set to be cuneiform.
... but only for constants.
-- c
Dan Sugalski [EMAIL PROTECTED] wrote:
I was using .locals for the actual variables in the source program,
Well, you know it: .locals aren't vars.
and $Px for all the temps the compiler generated. I've been migrating
a lot of the code to use a few .local-defined hashes and indexing
into
At 1:05 PM -0400 4/22/04, Aaron Sherman wrote:
On Thu, 2004-04-22 at 11:22, Dan Sugalski wrote:
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
More to the point, Perl 6's compiler will have to parse class Joe,
create a new object of type Class, parse and execute the following
block/closure
Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
Hello folks,
This will be of interest to only a few people, but it will be good
to have it in the archives for when we need it.
Here is a list of Korean character sets that represent hangul
(Korean symbols) and hanja (Sino-Korean):
On Thu, 2004-04-22 at 14:44, Dan Sugalski wrote:
At 1:05 PM -0400 4/22/04, Aaron Sherman wrote:
This is in direct contradiction to what I'm hearing from you, Dan.
What's the scoop?
The scoop is that
my Joe $foo;
emits the code that, at runtime, finds the class ID of whatever Joe's
On Apr 20, 2004, at 11:22 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Here's another tiny patch, to let us fast-fail string_equal if we have
cached hashval's which don't match.
What about a hash value collision?
If the hash values are equal, it proceeds on to do the full
At 2:48 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 21, 2004, at 7:33 PM, Dan Sugalski wrote:
At 11:17 AM -0700 4/21/04, Jeff Clites wrote:
On Apr 21, 2004, at 10:20 AM, Dan Sugalski wrote:
Just to make sure... we're making sure the strings are always
properly decomposed before comparing,
Aaron Sherman writes:
But according to A12 as I understand it, the part BEFORE that, which
looked innocently like a definition:
class Joe { my $.a; method b {...} }
would actually get turned into a BEGIN block that executes the body of
the class definition as a closure in class
On Wed, 2004-04-21 at 15:46, Larry Wall wrote:
On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
: The math folks tell me it makes sense. I can come up with a
: half-dozen non-contrived examples, and will if I have to. :-P
I've said this before, and I'll keep repeating it till
On Thu, 2004-04-22 at 15:37, Luke Palmer wrote:
But Perl 6 is tightly coupled with Parrot. Perl 6 will be a Parrot
program (even if it calls out to C a lot), and can therefore use the
compreg opcodes. That means that any code executing in Parrot can call
back out to the Perl 6 compiler, and
At 3:58 PM -0400 4/22/04, Aaron Sherman wrote:
On Wed, 2004-04-21 at 15:46, Larry Wall wrote:
On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
: The math folks tell me it makes sense. I can come up with a
: half-dozen non-contrived examples, and will if I have to. :-P
I've said
Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
lives, nobody's got much standing to call a character set Legacy :)
I suggest Parrot's native character set to be cuneiform.
... but only for constants.
Yeah, I was going to propose the Phaistos disc signs for the variable
Jens Rieks wrote:
It is and it isn't. The naming conventions say that struct
Parrot_Interp should really be struct parrot_interp_t, but that's a
ginormous global change. I've tried to implement it once or twice, but
my most recent attempt cause mysterious compile errors.
I've prepared a patch
On Apr 19, 2004, at 3:41 PM, Marcus Thiesen wrote:
As I'm currently at my fathers place I had the time and resources to
do some cygwin and native win32 testing.
Great!
I can't get it to work under Cygwin since the ICU changes because it
tries to
do some linking stuff that fails
...
Next I
49 matches
Mail list logo
