Re: Another approach to vtables

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 >

PDD X: Perl API conventions

> like we do in perl 5. Perl_ for functionish things, PL_ for dataish things. It's awhile I wanted to spark some discussion in this area and this comment made me want to write a PDD on API conventions. The result follows. Comments welcome. =head1 TITLE Perl API conventions =head1 VERSION 1 =hea

Re: PDD X: Perl API conventions

On 03/03/01 Damien Neil wrote: > > All the function names shall begin with the C 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 t

Re: PDD 4: Internal data types

> > 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 applic

Re: PDD 4 internal data types, version 1.1

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 C. Th

Re: An overview of the Parrot interpreter

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

Re: An overview of the Parrot interpreter

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 r

Re: An overview of the Parrot interpreter

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

Re: An overview of the Parrot interpreter

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

Re: An overview of the Parrot interpreter

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. H

Re: An overview of the Parrot interpreter

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 t

Re: An overview of the Parrot interpreter

On 09/06/01 Dan Sugalski wrote: > >The original mono interpreter (that didn't implement all the semantics > >required by IL code that slow down interpretation) ran about 4 times > >faster than perl/python on benchmarks dominated by branches, function > >calls, > >integer ops or fp ops. > > Right

Re: An overview of the Parrot interpreter

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

Re: An overview of the Parrot interpreter

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 s

Re: An overview of the Parrot interpreter

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 wh

Re: Supporting safe managed references

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 t

Re: Quick note on JIT bits

On 11/15/02 Gopal V wrote: > It is possible ... JIT generated code looks just like loaded code to > gcc ... Typically gdb should only need access to a symfile to correctly > allow debugging ... So an .o file of the JIT'd code should be correctly > generated with all the trimmings. > > $ gdb parr

Re: Quick note on JIT bits

On 11/16/02 Gopal V wrote: > > the above was a partial cut&paste 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 w

Re: Objects, finally (try 1)

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 w

Re: Objects, finally (try 1)

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 st

Re: This week's summary

On 07/16/03 Dan Sugalski wrote: > >> pit/pratfalls. At one point, Tupshin suggested emulating a 'more > >> traditional stack-oriented processor' and I don't think he was > >> joking... > >> > >Indeed, I wasn't, but I wish somebody would at least have the > >decency to tell me how insane this

Re: Registers vs. Stack

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

Re: ICU Outdated - Ideas

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 take

Re: register allocation

On 08/09/04 Leopold Toetsch wrote: > Dan posted some numbers: P 26951, S 2099, I 8878 for "evil program". The > program dies because of memory shortage when setting up the register > life information. Some time ago I used a 16 bit unsigned int to represent virtual registers in the mono JIT. Well,

Re: pmc_type

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

Re: pmc_type

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 t

Re: How to run typeless languages fast on parrot?

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 > run

Re: How to run typeless languages fast on parrot?

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

Re: Alignment Issues with *ManagedStruct?

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): [.

Re: pdd15_objects.pod, attributes, properties, and life

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.

Re: Classes and metaclasses

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 confusi

Re: newbie question....

My weekly perusing on parrot lists... On 03/12/04 Dan Sugalski wrote: > For example, if you look you'll see we have 28 binary "add" ops. > .NET, on the other hand, only has one, and most hardware CPUs have a Actually, there are three opcodes: add, add.ovf, add.ovf.un (the last two throw an ex

Re: [PATCH] more oo*.* benchmarks

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 tas

Re: Newbie Question

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." [...] > T

Re: Revamping the build system

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

Re: Revamping the build system

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:

Re: JIT compilation

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 >

Re: JIT compilation

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 si

Re: JIT compilation

On 11/08/01 Benoit Cerrina wrote: > I heard that, I was thinking that it would be great to run ruby on mono but > ruby is very dynamic (like perl but since its so much easier to use and > program > it is also easier to redefine the methods and done more often) There is an effort to compile ruby t

Re: JIT compilation

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

Re: JIT compilation

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 features-and-

Re: Mono and Perl6....

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 co

Re: Minor patch to make the GC count total bytes copied [APPLIED]

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: strin

Re: Minor patch to make the GC count total bytes copied [APPLIED]

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

Re: Backslashes

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 {

Re: RFC 326 (v1) Symbols, symbols everywhere

7 wallclock secs ( 5.97 usr + 0.00 sys = 5.97 CPU) In the internals using C the performance gains are way more than the 30% average here. So, both for internal use and as a language feature there are advantages, implementation is easy. If no one shows a significant drawback, it&#x

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

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

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

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, >