On 08/16/07 Joshua Isom wrote:
The optimization done by the parrot jit is invalid for the x86 C calling
convention: the area of memory containing the passed arguments
can be used as scratch space by the called function.
[...]
Let's go with a Microsoft blog about it,
On 08/16/07 Ron Blaschke wrote:
This optimization reaches likely back to times, when the opcode engine was
designed. It's saving one interpreter push statement [1] per JIT calling
one
external function, and I've always thought of it as a very cool (and valid)
thingy, when I first
On 01/24/06 Jonathan Worthington wrote:
.NET has these managed reference thingies. They're basically like
They are called managed pointers.
pointers, but safe. What makes them safe is that only certain instructions
can create them and the pointer value can't be set directly (we can do
On 10/29/04 Leopold Toetsch wrote:
Ugh, yeah, but what does that buy you? In dynamic languages pure
derivational typechecking is very close to useless.
Actually, if I were to write a perl runtime for parrot, mono or
even the JVM I'd experiment with the same pattern.
For the latter
On 10/27/04 Luke Palmer wrote:
Stéphane Payrard writes:
That would allow to implement typechecking in imcc.
.sym Scalar a
a = new .PerlInt # ok. Perlint is derived from Scalar
Ugh, yeah, but what does that buy you? In dynamic languages pure
derivational typechecking is very
On 08/03/04 Leon Brocard wrote:
IIRC the mono people wrote their own, but with the ICU data files.
Apart from license issues, this might be an interesting thing to look
at.
We use some of the ICU data files for locale info like day/month names,
date/time formats etc. We have a tool that takes
On 04/01/04 Goplat wrote:
I read in the FAQ, vis a vis using the .NET instead of writing your own
The .NET VM didn't even exist when we started development, or at least we
didn't know about it when we were working on the design. We do now, though
it's still not suitable.
[...]
Those VMs
On 03/21/04 Jarkko Hietaniemi wrote:
[...]
oofib 100%144%132%240%212%140%136%
[...]
That being said, people more conversant than me in Python/Ruby
(or Parrot) are welcome to carefully compare the scripts to verify that
the scripts really do implement the same tasks.
On 03/13/04 Mark Sparshatt wrote:
One difficulty is when calling class methods some languages require that
you provide the class object as the receiver (Ruby and c# do this) while
some languages let you use an instance of the class as the receiver
(Java does this)
I think you're confusing
On 02/27/04 Dan Sugalski wrote:
What .NET calls an attribute parrot calls a property
What .NET calls a property parrot calls an attribute
[...]
Oh, yeah. No matter which way we go we'll be confusing someone, since
there are languages that call what we call an attribute an attribute.
The
On 02/05/04 Uri Guttman wrote:
with this struct (from leo with some minor changes):
struct xt {
char x;
struct yt {
char i,k;
int j;
} Y;
char z;
} X;
and this trivial script (i pass the filename on the command line):
[...]
i get
On 11/06/03 Leopold Toetsch wrote:
because pmc as so much slower that native types i loose most of
parrots
brilliant speed due to the fact that i don't know the types at
compile-time.
When you get rid of all the temps and the clone[1], the loop with PMCs
runs at about
On 11/07/03 Leopold Toetsch wrote:
Very interesting. While we don't compete with typed languages, its nice
Oh, but mono _will_ also compete with dynamically typed languages! :-)
to see, that parrot execution speed is in the region of mono - for such
small tight loops.
Well, that was mono
On 08/21/03 Tom Locke wrote:
Note that I have *absolutely* no opinion on this (I lack the knowledge).
It's just that with Perl, Python, Ruby, the JVM and the CLR all stack based,
Parrot seems out on a limb. That's fine by me -- innovation is not about
following the crowd, but I feel it does
On 01/11/03 Nicholas Clark wrote:
This allows us to declare 8bit characters and strings of those and all the
stuff we're used to with C like unions ... (C# has 16bit chars, and strings
are UTF8 encoded , IIRC) ...
That doesn't sound right. But if it is right, then it sounds very wrong.
On 01/12/03 Gopal V wrote:
If memory serves me right, Paolo Molaro wrote:
The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as
far as it's visible to the 'user' programs).
1023.2.3 #Strings heap
11 The stream of bytes pointed to by a #Strings header
On 11/16/02 Gopal V wrote:
the above was a partial cutpaste with s/mono/parrot/ :-)
But don't act like you invented it Kaffe had one before you thought
about mono JIT ...
The idea probably predates kaffe, too. Anyway, I didn't say I had the
idea, but the implementation. Quoting what
On 05/21/02 Aaron Sherman wrote:
On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
Here's an easier one: backslash followed by the delimiter is that thing.
Everything else is literal.
print 'c:\it\'s\easier\to\write\win32\paths\this\way';
print q{this is ok { and so is
On 04/12/02 Dan Sugalski wrote:
FWIW, the numbers were:
No JIT: Parrot 866 gen/sec Mono 11 gen/sec
JIT: Parrot 1068 gen/sec Mono 114 gen/sec
Interesting data: was this taken a while ago?
I get different ratios on my machine (PIII 1.1):
Parrot JIT: 850 (though the output is
On 04/11/02 Dan Sugalski wrote:
I'm not sure which is worse--the amount of data we're copying around,
or the fact that we eat Mono's lunch while we do so.
:-)
Could you post the code for the sample? Is it based on the snipped Simon
posted a while ago where it used the pattern:
string
On 02/06/02 Larry Wall wrote:
Black pots and kettles aside, they bring up a lot of interesting issues
that we have to think about if we're going to be more language-neutral
than the CLR.
The main issue is that there is a point where too much generality
will make the VM too hard to target code
On 11/17/01 Dan Sugalski wrote:
BTW: we just got our compiler running on linux and compiling a simple
program, hopefully by next week it can be used for some more real code
generation.
Yahoo! Congrats. Are we still slower than you are? :)
It's a couple of months I'm in
On 11/16/01 Simon Cozens wrote:
On Fri, Nov 16, 2001 at 03:32:06PM +0100, Paolo Molaro wrote:
And there is someone working on python
support in the mono compiler, too.
I know, I've just seen. Wouldn't it be really wonderful, Paolo, if
someone wrote some Perl bindings for it as well
On 11/07/01 Ken Fox wrote:
Simon Cozens wrote:
... Mono's work on JIT compilation ... they've got some pretty
interesting x86 code generation stuff going on.
Mono is doing some very cool stuff, but it's kind of hard
to understand at this time. The x86 code generation macros are
easy to
On 11/08/01 Norbert Bollow wrote:
BURG means Bottom-Up Rewrite Grammar... a way to generate
optimized code quickly *if* you have plenty of memory available.
Maybe, if 32 KB for a large method is plenty (about 600 bytes of IL code):
basically all the methods in out corlib are below that size.
On 10/23/01 Simon Cozens wrote:
On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
1) Build minimal perl 6 with default parameters using platform build tool
But platform build tool is going to be 'make' - the alternative is
that we maintain and ship every flavour of batch or
On 10/23/01 Simon Cozens wrote:
On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
autoconf automake libtool
MVS, MacOS, cross-compilation.
cross-compilation is not an issue at all with auto* (I'd say it makes it
almost easy to support it).
MacOS: I guess any type
On 09/07/01 Dan Sugalski wrote:
The only optimizations that interpreter had, were computed goto and
allocating the eval stack with alloca() instead of malloc().
Doesn't this really get in the way of threading? You'll chew up great gobs
of system stack, and that's a scarce resource when
On 09/05/01 Nick Ing-Simmons wrote:
It's easier to generate code for a stack machine
True, but it is easier to generate FAST code for a register machine.
A stack machine forces a lot of book-keeping either run-time inc/dec of sp,
or alternatively compile-time what-is-offset-now stuff. The
On 09/05/01 Dan Sugalski wrote:
It's easier to generate code for a stack machine
So? Take a look at all the stack-based interpreters. I can name a bunch,
including perl. They're all slow. Some slower than others, and perl tends
to be the fastest of the bunch, but they're all slow.
Have a
On 09/05/01 Hong Zhang wrote:
I think we need to get some initial performance characteristics of register
machine vs stack machine before we go too far. There is not much points left
debating in email list.
Unfortunately getting meaningful figures is quite hard, there are
so many thing to
On 09/06/01 Dan Sugalski wrote:
Okay, I just did a test run, converting my sample program from interpreted
to compiled. (Hand-conversion, unfortunately, to C that went through GCC)
Went from 2.72M ops/sec to the equivalent of 22.5M ops/sec. And with -O3 on
it went to 120M ops/sec. The
On 09/06/01 Dan Sugalski wrote:
Then I'm impressed. I expect you've done some things that I haven't yet.
The only optimizations that interpreter had, were computed goto and
allocating the eval stack with alloca() instead of malloc().
Of course, now it's slower, because I implemented the full
On 09/04/01 Dan Sugalski wrote:
Regardless, it's the way we're going to go for now. If it turns out to be a
performance dog then we'll go with a stack-based system. Initial
indications look pretty good, though.
Care to share some numbers/code for that?
You're right that optimization
On 09/04/01 Uri Guttman wrote:
does it really matter about comprehension? this is not going to be used
by the unwashed masses. a stack machine is easier to describe (hence all
the freshman CS projects :), but as dan has said, there isn't much
mental difference if you have done any serious
On 09/02/01 Simon Cozens wrote:
=head1 The Software CPU
Like all interpreter systems of its kind, the Parrot interpreter is
a virtual machine; this is another way of saying that it is a software
CPU. However, unlike other VMs, the Parrot interpreter is designed to
more closely mirror
On 03/03/01 Damien Neil wrote:
All the function names shall begin with the Cperl_ prefix. The only exception
is function names that may be used only in the perl core: these names shall
begin with the C_perl_ prefix. This will make it possible to export only
the perl_* functions from the
Most won't, honestly. At a guess, 90% of perl's current userbase doesn't
care about Unicode for any reason other than XML,
The next version of Gtk+ will use utf8. Qt use unicode already. Tk
will probably move in the same direction if it doesn't do it already.
So most user interface
On 03/05/01 Dan Sugalski wrote:
=item Arbitrary precision integers
Big integers, or bigints, are arbitrary-length integer numbers. The
only limit to the number of digits in a bigint is the lesser of the
amount of memory available or the maximum value that can be
represented by a CUV. This
On 02/07/01 Edwin Steiner wrote:
[snip]
I thought about it once more. Maybe I was confused by the *constant* NATIVE.
Are you suggesting a kind of multiple dispatch (first operand selects
the vtable, second operand selects the slot in the vtable)?
So
$dest = $first + $second
becomes
40 matches
Mail list logo
