Re: [perl #32421] Bug: segfault in imcc parsing bad if statement
Segfault in the lexer. Bad. 349 sprintf(label, %s%d, yytext, frames-label); (gdb) p frames $1 = (struct macro_frame_t *) 0x0 I didn't know how or why or what a frame is in this context which is why this isn't a patch :) __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Re: Last bits of the basic math semantics
Hi, fixed sizes of integer, so I'd aim some ops at low-level types of known size and leave it at that. Quite a while back, I did add a few opcodes for fixed size integer operations for Parrot .. But they were added for a totally different HLL :) matter what you do with the high bits. I suppose another way to look at it is that they'll just want ops that'll JIT well, which usually means to make the ops work on the natural datatype sizes of the machine. But that fights against the fact that most crypto algorithms do their commutations based on a known number of bits. Maybe the dotgnu.ops needs to be renamed as fixedsize.ops and add a few more fixed size int operations ?. int , uint, long and ulong should suffice for most crypto folks , but those ops are not JIT'd AFAIK. Gopal
Re: The encoding API
Hi Dan Michael,
As a guy who speaks a strange language (multi byte chars, multi glyph
chars, caseless
text and half vowels) , I think you have made it too complicated than
it should be .
charset end of things, offsets will be in graphemes (or Freds. I
don't remember what we finally decided to name the things))
Writing a unicode composition and rendering is VERY VERY HARD ...
Find a way to leech that ... (I've tried a pango module for malayalam and
it's really really hard to do).
When dealing with variable-length encodings, removal of codepoints in
the middle may make the string shrink, and adding them may make it
grow. The encoding layer is responsible for managing the underlying
byte buffer to maintain consistency.
It was soo easy with immutable strings ... I think that is why Java could
implement unicode properly :)
void to_encoding(STRING *);
Make the string the new encoding, in place
A String should always be Unicode IMHO , they should be converted to
byte buffers
by encoding and back from byte buffers while decoding.
UINTVAL get_codepoint(STRING *, offset);
void set_codepoint(STRING, offset, UINTVAL codepoint);
*if* , String always contains (length, UINTVAL[]) always , doesn't it
make life easier ?
UINTVAL get_byte(STRING *, offset)
...
Byte offset. Needs more clarity.
...
void set_byte(STRING *, offset, UINTVAL byte);
...
My advice would be to never let the layer above the encoding know that
we're storing
it in bytes :)
STRING *get_codepoints(STRING, offset, count);
Immutability of returned string (and original) would save memory ..
especially the UINTVAL
array was GC allocated :) .. of course what you have here is the
substring operation in
a new and obfuscated name :)
// some psuedo code as I see it.
substring(string, offset, count)
{
// validate params or catch fire and exit
string2=gc_alloc(string_header);
string2-length = count;
string2-data = (string-data[offset]); // hopefully data is also gc_alloc'd
return string2;
}
I'm afraid your design is waaay too complicated, at least for an
average guy like me .
I'd like to suggest that all STRING be unicode and convert to byte
buffers and back for all
other purposes. But that's just a suggestion :)
Gopal
Re: This week's summary (gcc and parrot)
If memory serves me right, Paolo Molaro wrote: You're insane. :) Why does this sentence keep popping up whenever anyone discusses modding gcc :) registers, and register starvation's one of the more annoying things a compiler has to deal with. imcc ! But this is what Dan had to say about compiling C to Parrot (conversation dated: 2002-10-19) [11:31] rhysw Dan: to go off on a different tangent now - C support [11:31] rhysw Dan: compiling C to Parrot, that is [11:31] Dan Ah, that. Yeah, definitely doable. It'll be rather slow, though [11:31] Dan Our function call overhead's rather large compared to what C needs [11:32] Dan Still, I find the thought of C with native continuations rather interesting. Scary, but interesting [11:32] rhysw Dan: I was more thinking of the memory layout issues. C code is very particular about struct layout, array representation, etc. I didn't see any opcodes that would allow one to do pull an int32 out of offset N from this pointer. [11:33] Dan C's not at all particular about struct layout, unless they changed the standard. [11:33] Dan Still, you can do them either with struct PMCs, whcih'd be slowish, or with the pack/unpack opcodes, which I bet are insufficiently documetned [11:35] Dan Still, the packed structures need more thoght. Hrm. [11:35] rhysw Dan: I suppose a better question would be is supporting C a goal, or would it just be a cool hack but otherwise uninteresting? [11:36] rhysw because, as you say, it wouldn't be terribly efficient ... [11:36] Dan Neither, really. It's interesting in the sense that it'd let people use code that they otherwise couldn't, if they don't have a C compiler for. [11:36] Dan But it's definitely not a primary goal [11:36] Dan Consider it both mildly interesting and mildly bemusing :) So ... the verdict then was mildly interesting ... and the partly done pm_codegen.tc is still commented out ... is there any change now ? There is already a (limited) gcc backend that targets the CLR that sets up an area of memory for that use, but, as you can guess, it's not vey nice. Currently I can dump stack opcodes (like the CLR) using a triple var (or rather temporaries) code generator off AST .. and directly translate stack opcodes to Parrot without any of the stack++ crap .. almost making half the JIT-time operations during compile time . I've used that idea to build a small mathematical expression compiler which dumps IL or Parrot (and acme did the perl5 codegen)... I think a gcc port would require parrot to provide at least a stack memory area and a register (sp) that points to it. No, actually I think the gcc backend could lighten up on the register allocation and just add new temporaries as needed ... also there are no special registers for parrot which makes it a bit easier too .. All I can say is that PMCs might be underutilized in this model. There may be other issues with the parrot instruction set, but since you have already hundreds (or thousands?) of opcodes, I guess it wouldn't be an issue to add a few more if needed:-) I object ... no special registers or stack areas please .. Gopal -- The difference between insanity and genius is measured by success
Re: Class instantiation and creation
If memory serves me right, Dan Sugalski wrote: It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of newclass, addparent, addattribute ops, assuming those are the op names we go with. Classes just get created at code initialization time or something. That would be cool .. a lot easier to debug this kind of thing , especially when you could dump it as imcc and have it constant evaluated as a bytecode segment (wishful thinking ;) Question #1 : Are classes allowed to have fields ? Question #2 : Visibility ? Question #3 : Static methods ? Question #4 : Static constructors ? Question #5 : Destructor semantics .. Questions #3 #4 can be emulated and #2 is only optional but #1 #5 are of concern .. instantiate a new class you need a chunk of bytecode around. It's possible that at least some of this is only doable with metadata in bytecode, but the bytecode metadata segments can be easily created on the fly. Hmm... like compile some imcc on the fly ? Anyone got any feelings or opinions on this, besides Why yes, I want an object system? :) Class-based info I may be missing would also be welcome. Why who wouldn't ? How would the override of a method happen ? ... would it be purely by name or would you provide some way to force a method to override another of a different name ? .. Ie add a method forcibly over an occupied slot ?. Gopal -- The difference between insanity and genius is measured by success
Re: Make mine SuperSized....
If memory serves me right, Leopold Toetsch wrote: I'm - as stated in the thread - for a new register type (L, long). I'm thinking of virtual registers here... ie if sizeof(INTVAL) == 4 'L' is a PMC else if sizeof(INTVAL) == 8 'L' is an INTVAL So 64 bit opcodes are compiled in differently for each platform ? ie add a set of virtual 'L' registers which turn into 32 new PMC regs in 32 bit and 32 new INTVALs in 64 bit systems ? To take away the choice deep down into the JIT compile time ? (actually when the JIT is compiled time :-) Since due to an accident , we have conv_i8 as an opcode and not as an explicit PMC call , we should be able to #ifdef it's internals to match the hardware ?. This should hard-code it after compilation with none of the runtime overhead. After all we saw lots of C compilers do something similar for floats :-) Gopal -- The difference between insanity and genius is measured by success
Re: Make mine SuperSized.... (integers only ;)
If memory serves me right, Bryan C. Warnock wrote: Reply inline ... and I've said more than I've quoted ... It could be called as a critical appreciation ... though not much has been appreciated below ... and what I know about parrot can be written on a shirt sleeve ;-) Please do tell me if I've gone off the track below. If the hardware can do 64-bit math, and the compiler can produce the code to do 64-bit math on the hardware, then languages running atop Parrot should be able to do 64-bit math on the hardware. What I wanted to say was to have fixed size variables and an interpreter specific internal notation would be ideal. And only if you wanted to operate stuff with direct int registers.. The fixed size variables allow the JIT to decide if we use half-a-register , one or two for each operation according to hardware. Though I must say this is totally against the INTVAL philosophy ... But I think the INTVAL philosophy is a creep of a Perl idea into Parrot ie having variable size integers to execute ... Why this interpreter concept (ie perl5) ended up in the engine instead of the code production phase shows how blurry the distinction is for Parrot Perl6 . So compiling perl6 code with --with-64bit-integers (or something like that) will use the Int64 instead of Int32 for all int variables without affecting the array indexing , addressing features. Thus the engine can adopt the policy of The compiler asked for Int64 and let it go at that. So we standardize data/integer sizes after the packfile phase of Perl6 code. So after compiling something that needs 64 bit ints , you could pick it up and run it in a Parrot configured to 32 bit operations and it will use Int64 (2 registers, register pairs or software emulation -- JIT picks) since that is mentioned explicitly in code . And we'll all be happy. Similarly for 32 bit code compiled and ran on a 64 bit platform will have the correct semantics overflow modes as it is explicitly mentioned as Int32 in the packfile. Having said all that ... Isn't it a bit too late to bring this up ? The reason these were made into new ops instead of PMCs was to allow JIT'ing these in the future if needed ... They are simple enough to be easily JIT'd, but better wait until they are used :-) Good point. But for most supported languages other than those statically typed - ie, Parrot's tier 1 audience - those operations are going to be vectored through PMCs anyway. Perhaps even for statically typed languages. After all, Parrot really only has one size register. Have we provided full semantics - like overflow - for all supported integer sizes? Another point ... how are PMC methods called ?. Do they cause a register flush ?. Ie do you push registers before moving into a PMC ?. Because in x86, an Int32 addition is 1 instruction and a (reg,reg) = (reg) operation as well. Being able to do it inline rather than pass through a stack push, call and pop is also another speed factor. Such a register flush back to memory would have the a side-effect on the perfomance .. Especially when *all* numerics are via PMCs. I think that with most languages handling their numerics via PMCs, there are few places within Parrot that need to built around long longs on a 32-bit platform. (Technically, we can't even *guarantee* long longs on a 32-bit platform.) You're making me wonder if Parrot_Int4 should be the user/lang space type and INTVAL the interpreter space type , instead of otherwise. As Leo and I both documented, the integer registers are iffy. We don't know. Neither do I ... I'm just saying what I can see ..And of course I'm waiting for Dan and Leo to pounce on this thread (and hopefully they'll be quick merciful ;-) Gopal -- The difference between insanity and genius is measured by success
Re: Parrot for windows?
If memory serves me right, Benjamin Goldberg wrote: whine I suppose if there isn't a windows binary out there, I could try downloading and installing a C compiler (gcc? djgpp?) and then compiling my own parrot... but I don't want to do that much work! /whine Cygwin ? ... I'm not using windows but I know quite a few people who are using cygwin or the mingw32 gcc for building Gnu'ish stuff on Windows. Cygwin might be better as it also comes with a perl5 interpreter to run the Configure.pl and stuff. Otherwise you might have to *buy* a version of VC++ or something. Gopal -- The difference between insanity and genius is measured by success
tail call stuff again
Hi, I was just wondering about the tail call confusion around here. Why not just mark a tail call in bytecode ?. This is not strictly a new idea , and is inspired by: In addition, each of these instructions may be immediately preceded by a tail. instruction prefix. This specifies that the calling method terminates with this method call (and returns whatever value is returned by the called method). The tail. prefix instructs the JIT compiler to discard the caller's method state prior to making the call from the ECMA 335 spec for IL. Wouldn't something like that be possible here instead of figuring out the tail call stuff at runtime ?. (more work for the compiler devs :-) Or am I totally off course here ?. Gopal -- The difference between insanity and genius is measured by success
Re: targeting parrot tutorial
If memory serves me right, Simon Wistow wrote: I'm not sure if the tutorial has gone anywhere but I cam across this earlier which may be useful as a start. Something about using TreeCC would be nice as well. What would you need about TreeCC ?. I think Rhys has written a nice write up for the Free Software Magazine's first issue a copy of which showed up in his site as well (southern-storm.com.au) I had written a very simple compiler targetting Parrot (IMCC) which also pushed out IL and Perl 5 (thanks to Leon Brocard) and one day might spit out Python and C as well. And all this from the same AST parser ! http://symonds.net/~gopalv82/code/expr_compiler.tgz which does for/while/if , integer variables string literals. I think it would be a nice starting point for people to poke a stick at treecc. I'd be happy to discuss anything about treecc (like if someone wants to write a perl6/5 gen for treecc) , but technical discussions about treecc are better off in [EMAIL PROTECTED] mailing list. Gopal -- The difference between insanity and genius is measured by success
Re: access to partial registers?
If memory serves me right, Leopold Toetsch wrote: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? I always thought bitwise and and or were the things to use to modify partial content ?. Though I can't say if that makes sense because INTVAL is not fixed and neither is the endianess of registers (IIRC they are not fixed ?). We have a very limited subset in dotgnu.ops. Those were written to support the fixed size integers and longs that C# needs (Int32 Friends). I think you could convert from/to sized integer values with those opcodes (conv_u4,conv_i4...). Parrot codegen for C# still awaits the second coming of the prophet Zarquon.. (to be accurate -- Object instructions ;) Gopal -- The difference between insanity and genius is measured by success
Re: Using imcc as JIT optimizer
If memory serves me right, Dan Sugalski wrote: This sounds pretty interesting, and I bet it could make things faster. The one thing to be careful of is that it's easy to get yourself into a position where you spend more time optimizing the code you're JITting than you win in the end. I think that's not the case for ahead of time optimisations . As long as the JIT is not the optimiser , you could take your time optimising. The topic is really misleading ... or am I the one who's wrong ? You also have to be very careful that you don't reorder things, since there's not enough info in the bytecode stream to know what can and can't be moved. (Which is something we need to deal with in IMCC as well) I'm assuming that the temporaries are the things being moved around here ?. Since imcc already moves them around anyway and the programmer makes no assumptions about their positions -- this shouldn't be a problem ?. The only question I have here , how does imcc identify loops ?. I've been using if goto to loop around , which is exactly the way assembly does it. But that sounds like a lot of work identifying the loops and optimising accordingly. To make it more clear -- identifying tight loops and the usage weights correctly. 10 uses of $I0 outside the loop vs 1 use of $I1 inside a 100 times loop. Which will be come first ?. Gopal -- The difference between insanity and genius is measured by success
Re: Using imcc as JIT optimizer
If memory serves me right, Leopold Toetsch wrote: I'm assuming that the temporaries are the things being moved around here ?. It is not so much a matter of moving things around, but a matter of allocating (and renumbering) parrot (or for JIT) processor registers. Ok .. well I sort of understood that the first N registers will be the ones MAPped ?. So I thought re-ordering/sorting was the operation performed. Direct hardware maps (like using CX for loop count etc) will need to be platform dependent ?. Or you could have a fixed reg that can be used for loop count (and gets mapped on hardware appropriately). does it. But that sounds like a lot of work identifying the loops and optimising accordingly. Loop info - loop 0, depth 1, size 2, entry 0, contains blocks: 1 2 Hmm.. this is what I said sounds like a lot of work ... which still remains true from my perspective :-) r-score = r-use_count + (r-lhs_use_count 2); r-score += 1 (loop_depth * 3); Ok ... deeper the loop the more important the var is .. cool. Gopal -- The difference between insanity and genius is measured by success
Re: [CVS ci] CGP - CGoto Prederefed runloop
If memory serves me right, Nicholas Clark wrote: I had a (possibly) impractical idea - computed goto / JIT (or even computed goto / prederef / jit) core I don't know whether this is possible: Inside a cgoto core have 1 extra op - enter JITted section. The bytecode is compiled by the JIT (at some point) - if there are a run of consecutive JIT-able ops, then issue a section (an isolated section) of machine code for those ops, and replace those ops in the bytecode with an op that calls that section. If there isn't a run of JIT-able ops, then just leave the ops as ops, and use the regular computed goto core dispatch. Are you discussing some sort of unroller for native code for some opcodes ? .. basic blocks ?. Anything too complicated to unroll is replaced by a jump back into the interpreter core ?.. This strategy has been used in pnet's engine (which is still a souped up interpreter) ... the motivation was ease of porting unrollers than full JITs, ie opcode by opcode . I'd envisage it becoming a win if PBC often ends up with tight, isolated loops that use a lot of JITted ops, but most of the code is ops we've not See the Unrolling section on Rhys's paper for a detailed discussion on this idea http://www.southern-storm.com.au/download/pnet-engine.pdf Speaking truthfully , all I know is that it lifts pnetmark score for loops by about 10 times . Hope it helps, Gopal -- The difference between insanity and genius is measured by success
Re: Bytecode metadata
If memory serves me right, James Michael DuPont wrote: JVM had a LineNumberTable and VarNameTable for debugging which were declared as ``attributes'' to each method in the .class tree. I suppose VarNameTable is totally irrelevant for Parrot ... I dont know that, what is it? Variable name table? If so, i think it might be good for debugging. Mapping between local vars and variable names ... because JVM has unlimited (well virtually unlimited) local vars, this works for the JVM. But since Parrot has only 32 registers , they get re-used for local-vars . I think using IMCC will in general mess around the registers numbers for the temporaries. So it doesn't make sense for Parrot to have a VarNameTable. I think Parrot is going to *need* reflection operations :) ... You might be able to extract information like you do with C# , with reflection looping over the methods. You might want to run C# in parrot, then you need it. Not really for C# support only ... Dynamic invocation will need it... ?php $a=foobar; $a(); // get method name foobar from global scope, run ? Something of this sort will need to occur .. C# is much easier as you already know what all types/method there might be and there's no dynamic member lookup :). I think it is meta-data, all information about the bytecode that might be interesting to a person, to understand what a give bytecode is and means, it's context, meaning, usage, and all that. it is all meta-data. You could argue about that , but IMHO except the basic Reflection stuff and debug information , all the other itty-bitty details are useless for the engine . Better keep it in a seperate file ?. (and build a cool bytecode analysis tool as well :) .line 42 life.fubar Again, nice to meet you again Mr. Victory, That's quoted off my fubar-to-IL compiler ... (that's what we call the f'uped beyond recognition pascal clone we ``implement'' in our lab). Cheerio, Gopal -- The difference between insanity and genius is measured by success
Re: Bytecode metadata
If memory serves me right, James Michael DuPont wrote: I just want to know how where we can put it. The Microsoft IL has a whole section on meta-data, AFAIK, that just holds the offset, line number and filename. IIRC the JVM had a LineNumberTable and VarNameTable for debugging which were declared as ``attributes'' to each method in the .class tree. I suppose VarNameTable is totally irrelevant for Parrot ... yes I agree, I just want to be able to reconstruct the tree for debugging or reverse engineering (if the compiler that produced the bytecode whats to produce this). Optimisations ? ... (bang, there goes the line numbers ;) Normally you dont need this information, I just want to know how I can store it if I *do* need it. The metadata from the c++ that i am extracting even exceeds the size of the sourcecode itself. yeah, that is the idea. Reflection and introspector require the meta-data, that can be read by special reflection operations. I think Parrot is going to *need* reflection operations :) ... You might be able to extract information like you do with C# , with reflection looping over the methods. Btw, your RDF stuff wouldn't be what I call metadata :) .. it's data itself in a pre-processed format. IMCC can pick out the chunks of IMC, generate bytecode, .line 42 life.fubar ? Gopal PS: don't look at me like that , I don't know anything about debugging eval()... -- The difference between insanity and genius is measured by success
Re: [Introspector-developers] Re: Bytecode metadata
If memory serves me right, James Michael DuPont wrote: Bah. That's parrot -o foo.o foo.pmc isn't it? And if we make C a parrot supported language we can even build parrot with parrot? Hmmm... bootstrapping 1. The gcc : I have %99 of the information about the function bodies of parrot c source code in rdf/xml. That could be fed to parrot. That would only be part of the issue ... generating stuff out of RDF AST's is only half of our trouble ... In fact , I think it would be much easier if someone managed to convert RTL into Parrot (a gcc backend) ... It won't be a hack like egcs-jvm since Parrot is already a register machine and has pointer instructions already ... 2. The pnet/C : there has been work done by Rhys to make a managed c compiler for pnet. Gopal has been working on a parrot bytecode emitter for Pnet. Well ... I haven't been working on parrot bytecode emitter ... It's just that we have a pm_codegen.tc treecc handler inside parrot which is stubbed up ... until I can do some kind of class generation for parrot, the C# AST cannot be used for anything useful. Also Dan was not so hot about having a C compiler for Parrot when he met Rhys on IRC... So I'm sticking to compiling C# to Parrot as an aim , and *maybe* Java as well ... Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Erik Bågfors wrote: :-) Python basically requires that each step in the process be overridable. (1. look up attribute 2. call attribute, at least in `callmethod's case). would this be more of what you need ? obj.__dict__[foo].__call__(); /me again shows up and says that the compiler designer can do this with ease ... Or in this case the interpreter designer can implement an ``InvocationExpression'' in anyway they want ... I think Jython would be a fine example of how this could be done (though speed suffers on a hash lookup without engine support ?). Ruby needs to call the missing_method method (if I remember correctly). So if foo doesn't exist, it would be good to be able to override callmethods behavior and make it call missing_method. like I said , the compiler designer can put that explicitly in the generated code ... You don't actually need instructions to do that. Also the explicit generation might prove to be better to handle all the quirks future languages might encounter My interest here is to obtain a clear and fast way to call stuff for static compiled languages. :) Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Erik Bågfors wrote: But if I write a library in ruby that depends on the missing_method method it will not be usable from other languages, since those languages doesn't call missing_method if the method they try to call doesn't exist. Hmm... that's twisting language features with virtual machine instructions. Actually that's a gray area as far as I can see ... we'll have to go on with `n' number of methods for `n' languages for member resolution ... Of course, in real life I don't think that's a problem because I haven't seen much use of missing_method. Unfortunately I use a lot of __getattr__ for my python code (especially GUI) ... Also, having a instruction would be faster which of course is more fun :) Yes... But this not only makes it ugly (as an instruction) , but slow as well ? . Like you said only a small number of people use this feature , does it make sense to slow down the rest ? . And how does hacker ZZ add a new language with a different member lookup without getting his patches inside Parrot ?.. Anyway I'm not *against* implementing this , I'm just questioning the *need* to implement this ... Just a question for the philosophers ... Gopal -- The difference between insanity and genius is measured by success
Re: Compiling to Parrot
If memory serves me right, Leon Brocard wrote: An interesting project to do would be to do a Java-Parrot compiler. Hmm... I think with the current Parrot setup that might be a bit difficult. We need object instructions for that , also I need to be able to define classes,interfaces and all the Java thingys there ... Basing it on an existing Java compiler such as Jikes is probably the best way to do this: Yikes ! (in a thick foreign accent)... My bachelor's project is a Java compiler for DotGNU ... and I had a look over of Jikes (and Kjc) for retargetting ... Eventhough I was planning on building a stack bytecode , I found it quite something to hack on... (in short, my attempts broke it...) Kjc is a bit more decent though it's quite OO and might take some redesign to pass back the result register (instead of assuming that the value is in the stack top) ... I've decided to base it on the Portable.net codegen... (I've got it into parsing now...) ... This is a Java - IL compiler from Java source ... But once the C# - Parrot compiler works , you might even have a Java - Parrot compiler ... (because I'm re-using almost all the C# AST nodes for my compiler, the PMCodegen should generate correct Parrot as well). Hopefully all this will work out for me... :) Gopal -- The difference between insanity and genius is measured by success
Re: Parrot compilers
If memory serves me right, Cory Spencer wrote: most example languages implement a complete compiler (ie lexxer - parser - optimizer - code emitter), which seems to be somewhat of a duplication of labour. Some are in C, others in pasm and yet others in Perl ... how do do you re-use libraries in that case ? ... Has or is anyone worked on a framework a la gcc gcc is not my ideal pick because it has an RTL bridge in between ... But I get the idea ... which would only require that new languages have a lexxer/parser written that coerced data into a standardized AST which could be passed off to other compilation stages? (Similarly, other end targets (such as Java bytecode or native code would only require the implementation of a new code emission module.) I have been working on just such a compiler collection , which generates .NET IL JVM from C# ... The next target is obviously Parrot and we plan at acheiving this by adding a new PMCodegen to the compiler backend. It uses a custom AST management tool (TreeCC) which should speed up development of ASTs. The system combines visitors and inhertiance to simplify compiler dev. Anyway treecc is there if you want to simplify AST management ... though I should say it's a bit different from OO or procedural programming ,it's aspect oriented... takes some getting used to. Take a look at the DotGNU portable.net's CSCC for examples, if you want to ... (and no, -mparrot will not work, though -mjvm might...) Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Jonathan Sillito wrote: x = a.f # get the method, a limited form of currying # since the first arg (a==self) is stored x() # output: A.f() setattr(A, f, g) # replace A's f with g a.f()# output: g() x() # output (still): A.f() !!! Which shows that the dispatch (i.e. selecting which method to call) can happen before the invocation. This makes sense let me put it in this way x_mthdptr=a.__dict__[f] a.__dict__[f]=g_mthdptr x_mthdptr() The dispatch vs invocation looks childishly simple when written this way.. (and I hope I'm right about that ... :) Underneath the high level language most things are really simple ... The Python compiler should work around all these language quirks and generate appropriate Parrot code ... In bytecode it should look direct, simple and fast !. Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Dan Sugalski wrote: rather than attributes, but I may be incorrect here. Are the current python instance attributes both: *) defined per object rather than per class *) Essentially global, that is not hidden from parent classes or anything. (Basically one big pool 'o things attached to the object) Speaking out of turn Python instance stuff is per Object ... And from the looks of it's just a dictionary lookup in the obj.__dict__ dictionary ... So the stuff looks essentially global. eg. class Foo: def __init__(self): pass def toString(self): return self.Name class FooBar(Foo): def __init__(self,name): self.Name=name a=FooBar(hello) print a.toString() -- hello Gopal PS: considering the fact that non-virtual functions are the only portion holding out the TreeCC Python plugin , I have had quite some heart burn with this. (or I need a switch statement :) -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
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 is the physical representation of the logical string heap. 13 but parts that are reachable from a table shall contain a valid null terminated UTF8 string. When the #String So I think the runtime does a UTF16 conversion , I suppose ...So you're right ... all C# programs get UTF16 strings to work with... but that's not the way they're in meta-data... (JVM also has UTF8 strings and 16 bit chars, it's not really a big issue :) But coming back to parrot ... I don't think parrot uses UTF8 (from what I could gather it seems to be all ASCII ?) ... Or is UTF8 hiding in somewhere ?... Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Nicholas Clark wrote: fussy. I presume Rhys is thinking about compiling C code to parrot, and then linking through to native C code (such as the native standard C library) via parrot. Nope ... At least for our .NET platorm stuff ,we are planning to compile glibc into IL so that the native ABI is accessed only via the engine. Most peices of glibc, depend on a few platform functions to run (most notably some in unistd.h) ... Most of the other peices of glibc can be directly used like the printf formatting code or file functions , once these underlying posix calls are in place... this is consistent with design philosophy of glibc which has been source portability rather than binary. So get your own glibc-managed.dll according to long,int, and char sizes :) without needing a C compiler, but you'd not be able to call out from your C code. We are facing a similar situation, but only that we have PInvoke (like your NCI) which allows you to define PInvoke methods from Managed C (I'd prefer the term Micro-Managed :) But the following does work for some functions :) extern int puts(const char *s) __attribute__((__pinvoke__(libc.so.6))); mm... ugly ! Rhys has also been really cool about the data stored via C ... So legacy code which used fixed size files (otherwise called records) will be useful. 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) ... In short, we will keep similar layouts in memory for structs and unions as far as possible ... (unions without offset based access to memory boggles my mind) So even with all the type-safety of IL we can run the following code ... float a=3.14; int b=*((int*)((a))); What Rhys is thinking about is potentially far more interesting, as it would What Rhys is using right now is a custom stdlib which is called pnetC and was just released ... People *really* curious about what Rhys is doing (and what those half-a-million lines are doing in DotGNU) should try the Portable.net C compiler (http://dotgnu.org/downloads/pnet/) .. We have mirrors on each gnu mirror as /projects/dotgnu ... (since we're likely to be slashdotted to death soon) Very, Very curiously ... I can call C# methods from Managed C, but not the otherway around :) .. and I can call native methods from Managed C , but that's dreadfully unportable like you said ... I'm really working only to get C# compiled to Parrot other language frontends in development like Java or C or JScript can wait a looong time. Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Nicholas Clark wrote: That doesn't sound right. But if it is right, then it sounds very wrong. (Translation: Are you sure about your terms, because what you describe sounds wonky. Hence if they are using UTF8 but with 16 bit chars, that feels like a silly design decision to me. Perl 5 performance is not enjoying a variable length encoding, but using an 8 bit encoding in 8 bit chars at least makes it small in memory.) I mean they're using UTF8 encoded strings ... and chars are 16 bit ... which means that reading chars from strings is wonky (from all I remember, ILString* uses int16[] for storing stuff... but the files do use UTF8).. Actually I think the ILImage functions in Portable.net abstract out the UTF8 reading and return int16* arrays ... Hope that makes more sense :) Ooh. So what happens if I try to run: char *a = 0; *a++; Assuming you meant (*a)++; ... coz *a++; is optimsed away into just a++; by GCC .. Does the VM just segfault the failing thread, rather than all threads in a process? How does this do for an answer ? Uncaught exception: System.NullReferenceException: The value 'null' was found where an instance of an object was required at Module.main() in segfault.c:3 at Module..start(String[]) Bye Bye segfaults, hello exceptions ... Hmm. So if DotGNU has a C to Parrot compiler, then we just compile the perl5 source code down to Parrot bytecode, et voilá, we have a perl implementation. This is assuming we can get all the perl5 dependencies compiled to Parrot without any issues ... (in fact this might be very,very hard... considering the fact that parrot codegen is still commented out for most of portable.net). I do hope no-one wanted it to go fast. :-) [then again, I wonder how the parrot JIT would cope] Which is why nobody is really interested in doing this :-) ... we're building the C compiler for fun ... So Rhys is mad: The difference between insanity and genius is measured by success I hope he falls on the right side of the divide. That's *my* sig ... and I'm attempting a cross-over :) Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
If memory serves me right, Chris Dutton wrote: Actually, if you really want Eiffel to compile to Parrot, it might be interesting to work on getting ANSI C to compile to Parrot first, since most Eiffel compilers use compilation to C as an intermediate step. This won't be too much of stretch We already have an ANSI C compiler working well with DotGNU pnet.. (with a IL output plugin)... log of=#dotgnu on=22-10-2002 [11:31] rhysw Dan: to go off on a different tangent now - C support [11:31] rhysw Dan: compiling C to Parrot, that is [11:31] Dan Ah, that. Yeah, definitely doable. It'll be rather slow, though [11:31] Dan Our function call overhead's rather large compared to what C needs [11:32] Dan Still, I find the thought of C with native continuations rather interesting. Scary, but interesting [11:32] rhysw Dan: I was more thinking of the memory layout issues. C code is very particular about struct layout, array representation, etc. I didn't see any opcodes that would allow one to do pull an int32 out of offset N from this pointer. [11:33] Dan C's not at all particular about struct layout, unless they changed the standard. [11:33] Dan Still, you can do them either with struct PMCs, whcih'd be slowish, or with the pack/unpack opcodes, which I bet are insufficiently documetned [11:34] Action: Dan apparently can't type this evening [11:35] Dan Still, the packed structures need more thoght. Hrm. [11:35] rhysw Dan: I suppose a better question would be is supporting C a goal, or would it just be a cool hack but otherwise uninteresting? [11:36] rhysw because, as you say, it wouldn't be terribly efficient ... [11:36] Dan Neither, really. It's interesting in the sense that it'd let people use code that they otherwise couldn't, if they don't have a C compiler for. [11:36] Dan But it's definitely not a primary goal [11:36] Dan Consider it both mildly interesting and mildly bemusing :) [11:37] fitzix Dan: It could make it very useful as a power tool [11:37] Kyeran Could someone toss up the Parrot URL so I can find out what it is? :) [11:37] fitzix Dan: sort of a swiss army knife kind of thing [11:37] Dan True, but I'm not willing to lose sight of the primary goal for it. /log Was our last conversation about Parrot C compilers .. We'll be adding a Parrot codegen for the compiler backend , as soon as the Objects are set in stone So possibly there exists a possibility for doing up the C compiler (with codegen tweaking) to develop a C compiler targetting Parrot. Gopal -- The difference between insanity and genius is measured by success
Re: Object semantics
If memory serves me right, Dan Sugalski wrote: Why would we want to avoid this? It looks exactly like what ought to happen. If you can provide that in-vm , it would be a lot faster ...(hmm, that's one argument that should convince you ;) But like I said , I need lots of sticky notes for all the opcodes for parrot ...(I'm still in can't remember all opcodes mode) Just because C# does it doesn't mean that he likes it. :) To end all further debate -- *) C# has something like this , *) I can't see what Dan has in head for parrot , *) I don't want feature creep into parrot *) Our C# - JVM compiler already has the workarounds for this like: invokestatic MyStruct copyIn__ (LMyStruct;)LMyStruct; *) I really don't like valuetypes that much :). *) Rhys will be doing most of the design , this is his headache actually :-) So does that cover all bases ? Gopal -- The difference between insanity and genius is measured by success
Re: Object semantics
If memory serves me right, Erik Bågfors wrote:
would a be able to modify itself ? (unfortunately C# allows that)
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=42; }
public override String ToString(){ return val.ToString(); }
}
public class FooBar
{
public static void Main()
{
MyStruct m1=new MyStruct(10);
MyStruct m2=m1;
m1.Modify();
Console.WriteLine(m1);
Console.WriteLine(m2);
}
}
=end cut
Which gives
42
10
If in anycase Parrot wants to avoid this , we could always add a special
case to the ILNode_Assign to generate an explicit copy step in parrot for
valuetypes...
So, workarounds are possible .. and neither the host nor the compiler
is there yet ;) ...
Gopal
--
The difference between insanity and genius is measured by success
Re: Object semantics
If memory serves me right, Dan Sugalski wrote: language-level we're object-oriented dammit! objects, not the lower-level stuff we're currently working with) should/will behave. yay ! ... finally ! reference-style objects and non-reference values. How large can a non-reference value be ? ... (in the .NET opcodes the 'struct' seems to be unlimited in size ...) But well, I'd settle for a non-reference of at least large integers (64bit)... And how will non-reference values dispatch methods ? ... would they be boxed into a reference for each method call, so that the method call can modify them ? ...or are all non-reference values immutable ? to put it down clearly ... MyValueType a; a.Modify(); would a be able to modify itself ? (unfortunately C# allows that) Gopal -- The difference between insanity and genius is measured by success
Re: Compiling to ParrotVM
If memory serves me right, K Stol wrote: I'm thinking of a compiler for Tcl which produces Parrot Assembly code, but the source language (which will be compiled) is not definite yet. Instead of generating Parrot assembly, you might find it easier to generate imcc code which is a simplified form . This takes care of the register allocation involved in Parrot assembly generation and spill over of registers. Writing your own register allocator is not advisable (unless you want to tear your hair out in bits peices). I have basic knowledge on compiler construction, but I think I can make a good start. The implementation language I'll use will most probably be C. If you're going to use C , please take a look at TreeCC which is a compiler tool for simplifying Syntax Tree traversal . It was developed for the DotGNU compiler collection and being used to build the C# C compilers now. (http://www.southern-storm.com.au/treecc.html) flex+bison+treecc has been demonstrated with multiple codegens (IL,Parrot) at http://symonds.net/~gopalv82/code/expr_compiler.tgz Hope it helps, Gopal -- The difference between insanity and genius is measured by success
Re: A work list! (Coming soon)
If memory serves me right, Nicholas Clark wrote: A Java bytecode to parrot bytecode translator Oh... the horror ... ! ... I wrote the entire JVM loading features of JILC (now in jilc.sf.net, because the savannah project got removed from inactivity).. I'm not working on or doing anything similar like the JILC (more due to being unmentioned on their website, than boredom) . Having said all that ... It would be good to wait for the Object stuff to start working before starting with something like this ... I'd think that having 32 Object registers (or are they going to be special PMCs ?), and the spillover tactics of imcc can take you there ... The question here, why would you need it ? ... (other than running Swing). A real Java compiler is more flexible and a better tool when it comes to optimized codegeneration ... Life was too simple when iload_0 iload_1became $I0=LOCVAR_I0 + LOCVAR_I1; iadd Let's move on a bit before planning this out ... (thankfully mapping 256 opcodes to a sparse set of 4 G opcodes is comparitively easier)... Gopal -- The difference between insanity and genius is measured by success
Re: A work list! (Coming soon)
If memory serves me right, Dan Sugalski wrote: What I'd like is for folks to take the next day or three to think of the things that they need parrot to do that aren't working or designed yet, and throw them at the list. (Try against the latest CVS, just to make sure that it's not gotten done when you weren't looking) In the mean time I'll work on my list, and we'll get a Big List 'O Things, throw them into RT, and start digging through them. Object support ! ... Gopal -- The difference between insanity and genius is measured by success
Re: [CVS ci] imcc syntax change
If memory serves me right, Leopold Toetsch wrote: WOuld it help to split imcc.y into main/parser/parser_utils or are you doing this anyway? yes pushing some code from imcc.y into a seperate file is what I had in mind ... But have not got to that yet ... Was curious about the following lines and sort of wasted that whole evening ... || return iANY(name, fmt, regs, 0); if emit (last param) is zero when called from INS ... when does the code actually get emitted ? So can I just do this to emit *.pbc ? emit_open(...) .. emit_close() to do my stuff ? (and how to do that without the interpreter interfering) So I sort of concluded to leave the output to direct fprintf's . Roughing it out with the changes in imcc seem easier than programming for this interface :-) Gopal -- The difference between insanity and genius is measured by success
Re: [CVS ci] imcc syntax change
If memory serves me right, Leopold Toetsch wrote: Yes, but I think, that incompatible changes shouldn't be necessary any more - sorry for breaking things. No problemo ... I just hate working on the same things again ... SymReg *r = mk_ident(char *name, char type) iANY(add, R3(r0,r1,r2)) Thanks, a shared library implementation of such a thing is what I'm looking for ... I'll take a look at doing that ... Gopal -- The difference between insanity and genius is measured by success
Re: Adding new function signatures to parrot's NCI call list
If memory serves me right, Leon Brocard wrote: Loaded... dlfunced... ../parrot: relocation error: /usr/lib/libSDL-1.2.so.0: undefined symbol: pthread_mutexattr_init I don't know if this is twisting the knife in the wound ... but it works for me ... [gopal@mushroom parrot]$ perl assemble.pl acme.pasm acme.pbc [gopal@mushroom parrot]$ ./parrot acme.pbc Loaded... dlfunced... SDL_Init worked just fine [gopal@mushroom parrot]$ How would I do this for the parrot code? You can't link in static libs (.a) with parrot or any other form of dlopen/dlsym ... Check if you have a libpthread.so somewhere ... if you have , then it will work (glibc-devel has it ,IIRC) .. And one *minor* point ... you'll need to do this in an Xterm .. the SDL libs need X11 to initialize .. Gopal -- The difference between insanity and genius is measured by success
Re: C#/Parrot Status
If memory serves me right, Rhys Weatherley wrote:
on 32-bit, 64-bit, and native-sized integer types (8-bit
types don't need it).
Hmm... maybe there's only one way to stop this lng thread ...
Oct 18 20:31:20 Nicholas no, no, you have it wrong. you don't
*ask* us to add features. YOu just send
us patches which do them :-)
Nov 25 03:09:38 Dan And I'm serious. If you want a dotnet.ops file,
go for it.
.
I couldn't make myself name it dotnet.ops so named it dotgnu.ops ...
DISCLAIMER: I don't know anything about how parrot opcodes should be
written .. So all errors are accidental and I would like somebody to
point them out to me ..
Gopal
--
The difference between insanity and genius is measured by success
/*
** dotgnu.ops
*/
#include parrot/method_util.h
VERSION = PARROT_VERSION;
=head1 NAME
dotgnu.ops
=cut
=head1 DESCRIPTION
Additional opcodes for C# compilation needed by cscc PM codegen
=cut
inline op conv_i1(inout INT) {
$1= (int)((char)($1));
goto NEXT();
}
inline op conv_i1_ovf(inout INT) {
if($1 = -128 $1 = 127) {
$1= (int)((char)($1));
}
else {
internal_exception(1, Overflow exception for conv_i1_ovf\n);
}
goto NEXT();
}
inline op conv_u1(inout INT) {
$1= (int)((unsigned char)($1));
goto NEXT();
}
inline op conv_u1_ovf(inout INT) {
if($1 = 0 $1 = 256 ) {
$1= (int)((unsigned char)($1));
}
else {
internal_exception(1, Overflow exception for conv_u1_ovf\n);
}
goto NEXT();
}
inline op conv_i2(inout INT) {
$1= (int)((short)($1));
goto NEXT();
}
inline op conv_i2_ovf(inout INT) {
if($1 = -32768 $1 = 32767 ) {
$1= (int)((short)($1));
}
else
{
internal_exception(1, Overflow exception for conv_i2_ovf\n);
}
goto NEXT();
}
inline op conv_u2(inout INT) {
$1= (int)((unsigned short)($1));
goto NEXT();
}
inline op conv_u2_ovf(inout INT) {
if($1 = 0 $1 = 65535) {
$1= (int)((unsigned short)($1));
}
else
{
internal_exception(1, Overflow exception for conv_u2_ovf\n);
}
goto NEXT();
}
inline op conv_i4(out INT, in NUM) {
$1= (int)($2);
goto NEXT();
}
inline op conv_i4(out INT, in PMC) {
$1= (int)($2-vtable-get_integer(interpreter, $2));
goto NEXT();
}
inline op conv_u4(out INT, in NUM) {
$1= (unsigned int)($2);
goto NEXT();
}
inline op conv_u4(out INT, in PMC) {
$1= (unsigned int) ($2-vtable-get_integer(interpreter, $2));
goto NEXT();
}
inline op conv_i8(out PMC, in INT) {
$1-vtable-set_integer_native(interpreter, $1,$2);
goto NEXT();
}
inline op conv_i8(out PMC, in PMC) {
$1-vtable-set_integer_same(interpreter, $1,$2);
goto NEXT();
}
inline op conv_i8(out PMC, in NUM) {
$1-vtable-set_integer_native(interpreter, $1,(int)$2);
goto NEXT();
}
inline op conv_r4(out NUM, in INT) {
$1= (FLOATVAL)($1);
goto NEXT();
}
inline op conv_r4(out NUM, in PMC) {
$1= (FLOATVAL) ($2-vtable-get_number(interpreter, $2));
goto NEXT();
}
Re: C#/Parrot Status
I guess I have more to learn about writing opcodes for parrot ... But all I can say is you people make it almost too easy :-) If memory serves me right, Leopold Toetsch wrote: The INTVAL could be a long long. Ok ... /me sort of needs an Int32 there ... Parrot_Int2 will be generated by a test in config/auto/somewhere and will be short. I asked the IRC room Nov 25 16:23:21 gopz on a related note .. does parrot size types ? Nov 25 16:23:33 gopz sort of like a Int8 I could cast to ? Nov 25 16:24:19 pdcawley I just write the summaries. Nov 25 16:24:52 gopz :-) . Sure, made note of Parrot_Int2 for future use ... inout, because the PMC has to exist in advance, and isn't emerging new here, like an int or num. OK .. The vtable function has to do the conversion. Yes.. especially if I have to use it for Float to Int64 ... Thanks for correcting my errors, Gopal -- The difference between insanity and genius is measured by success
What dotgnu.ops does (Re: C#/Parrot Status)
If memory serves me right, Gopal V wrote:
I couldn't make myself name it dotnet.ops so named it dotgnu.ops ...
On nicholas' advice I'm writing out the expected results for all
these opcodes... in the hope that someone more well versed in writing
..t files than me can help ..
conv_i1 conv_i1_ovf
-
Truncate to between (-128 and 127) so 128 converted to -128 ... 0 to 0
and the basic sign extensions of `char' apply here . 'ovf' suffix
instruction throws an OverFlowException message if the value is not
between -128 and 127. (TODO: throw catchable exceptions)
conv_u1 conv_u1_ovf
-
To between 0 and 255 ... ovf throws the OverFlowException if value not
in range. Original post bugs out for 256 ... See attached patch
conv_i2 conv_i2_ovf
-
To between -32768 and 32767 .. ovf for out of range
conv_u2 conv_u2_ovf
-
To between 0 65535 ... ovf for out of range
conv_i4
---
NUM to int : 3.1415 to 3 , -3.1415 to 3
PMC to int (until csint64.pmc is done...try testing with perlint please ..)
conv_u4
---
NUM to unsigned int: 3.1415 to 3, -3.1415 is not 3
PMC to int (when csint64.pmc is done ...)
conv_i8
---
(int to csint64.pmc , NUM to csint64.pmc ...)
conv_r4
---
(PMC to floatval) ... to be implemented as csint64.pmc
test 3 to 3.000 ... (not much of a test , eh ?)
I'll try to catch up on PMC writing at leisure ..
Gopal
--
The difference between insanity and genius is measured by success
--- /tmp/dotgnu.ops Mon Nov 25 21:26:31 2002
+++ dotgnu.ops Mon Nov 25 21:27:02 2002
@@ -38,7 +38,7 @@
}
inline op conv_u1_ovf(inout INT) {
- if($1 = 0 $1 = 256 ) {
+ if($1 = 0 $1 = 255 ) {
$1= (int)((unsigned char)($1));
}
else {
Re: Native function calls
If memory serves me right, Dan Sugalski wrote: I do actually like it. I was shooting for simplicity with the assumption that, since we were calling out to non-parrot-aware code, all bets were off with respect to type safety. If you load in libgtk.so and call functions dynamically there's not much we can do with respect to proper security. Well IMHO you can't add in any type safety in between parrot and C ... All I am suggesting is that .. 1) As far as possible .. have a sort of extern declaration in parrot domain, so we get a warning from the compile when I try to call that function in the .pbc file ... Sort of proxy for the native call ?.. A sort of check for type of param and number ... 2) When you are using it directly (unsafe) ... you deserve it if it blows up ... dlopen , dlsym does it frequently with me ... ;-) This 2 pronged approach is IMHO the ideal way ... afterall perl is all about many ways to do the same thing ... But well ... I should admit , I'm just trying to make the C# to parrot compilation as safe as IL (PInvoke and stuff...) No problem with that. I think you're not going to get it by default, since my big thing's speed, but it does mean we need to reevaluate things, since we need typechecking in safe code. Well if we can generate verifiable IL ... we should be able to generate type-safe Parrot code ... That's more of a language feature than bytecode feature .. What I was concerned was that we wouldn't have an extern definition for the native call to check if the actual params in C# are correct and of the same type as the formal params of the native func... Especially if we're going to check the calls before runtime ... (as is customary in static typed languages)... Hope I make myself clear, Gopal -- The difference between insanity and genius is measured by success
Re: C#/Parrot Status
If memory serves me right, Leopold Toetsch wrote: Please have a look at include/parrot/datatypes.h. I hope that there are all types you'll need. It seems so ... but I'm not really certain about Float data types ... Can you specify, what opcodes you would need? Hmm... I guess I can only quote the ECMA spec here ... conv.i1 Convert to int8, pushing int32 on stack conv.i2 Convert to int16, pushing int32 on stack conv.i4 Convert to int32, pushing int32 on stack conv.i8 Convert to int64, pushing int64 on stack conv.r4 Convert to float32, pushing F on stack conv.r8 Convert to float64, pushing F on stack conv.u1 Convert to unsigned int8, pushing int32 on stack conv.u2 Convert to unsigned int16, pushing int32 on stack conv.u4 Convert to unsigned int32, pushing int32 on stack conv.u8 Convert to unsigned int64, pushing int64 on stack conv.i Convert to native int, pushing native int on stack conv.u Convert to native unsigned int, pushing native int on stack Thanks to the polymorphic nature of the opcodes the from entry is in another table in ECMA But I guess conversions of lower integer data types to I registers and back would be a starting point ? Gopal -- The difference between insanity and genius is measured by success
Re: C#/Parrot Status
If memory serves me right, Leopold Toetsch wrote: Hmm... I guess I can only quote the ECMA spec here ... conv.i1 Convert to int8, pushing int32 on stack truncate to [-128..127]? And why the push? IL is a fully stack language ... pop int32, trunc, push int8 ... Yes, truncate is the required operation . I guess sign-extension is also present for up conversion ... What is the behaviour on overflow? *.ovf suffixed instructions like (conv.i1.ovf) exist seperately .. but that could be remedied by an explicit check ? ... Datatypes bigger then INTVAL would need a PMC as storage. Ok. Otherwise this would complicate register handling ? (jvm allocates 2 adjacent local variables for a long and double .. *yow*) Gopal -- The difference between insanity and genius is measured by success
[OT] Re: Quick note on JIT bits
If memory serves me right, Paolo Molaro wrote: If you think you have novel ideas in the JIT (or in the intepreter) space, you're probably just deluding yourself. sarcasm Oh yes I said that debuggable JIT is one of my very own personal ingienous ideas . /sarcasm This list for people who are interested in parrot and its VM Which is why I posted that info .. But I cannot see the same motive behind your mail ... If you can find a better implementation than mono's, I'd like to know about it, too:-) Guess I'll have to wait until the Parrot guys finish *sigh*, do you Ximian people never quit stalking me ? ... NOREPLY, Gopal -- The difference between insanity and genius is measured by success
Re: Quick note on JIT bits
If memory serves me right, Leopold Toetsch wrote: pusha/popa is overkill. The called functions always save bp and bx,di,si when used. ax is the return value, remaining is dx (cx is used by shifts) - i386 of course. Ok ... push_necessary() ;-) ... Speaking about debugging calls from JIT'd code ... Does parrot JIT generate a debugging segment ? like a dwarf2 segment so that we can debug with gdb ? ... (I hate it when I see 200 ?? in a backtrace). That would be a really nice feature. Can we - and how - handle over debug info to a running gdb? 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 parrot (gdb) run -debug=dwarf2 --break __main__ Foo.pbc (gdb) call Parrot_debug_make_syms() (gdb) add-symbol-file Foo.o Reading symbols from Foo.o (gdb) frame #0 __main__ at Foo.py:5 (HINT: where's the python compiler :-) The trick here is to use `gas' or the gnu assembler to generate the debugging info from the assembly dump you provide ... For example a function would be dumped as... ..string Func ..byte 0x13 ; METHOD_RETVAL ..byte 0x01 ; _public ..byte 0x00 ; _none (not virtual) ..long .L_TYPE_0 - .L_debug_info_b ; return type at label . This would mean that in debug mode the JIT will have to turn off all the optimisations and that the packfile contains a linenumber table or something similar ... (maybe even the whole source program too.. like gcc does ..) This is just an idea ... I'm too busy in DotGNU to try this out now .. And we have no JIT to do this stuff ... just an X86 code unroller for simple instructions sort of like the u-v pipelines in pentiums .. the fast x86 run or slow interpret according to instruction complexeties .. There this idea would mean gdb has to debug both the modes together Hth, Gopal -- The difference between insanity and genius is measured by success
Re: Source code analysis (was: Would a getting started guide help)
If memory serves me right, Tim Bunce wrote: CCured is a source-to-source translator for C, which analyzes the program to determine the smallest number of run-time checks that must be inserted in the program to prevent all memory safety violations. Yow ! .. the output looks __WILD ... Gopal -- The difference between insanity and genius is measured by success
Re: Quick note on JIT bits
If memory serves me right, Paolo Molaro wrote: You can find the complete examples of how the jit debugging features work in the mono tarball (mono/doc directory): Same old lupus I never realized I had a wolf pack hunting me :-) 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 ... http://www.kaffe.org/doc/kaffe/FAQ.xdebugging I just saved some typing by cut-pasting what I had in my box And don't bother to thank me for introducing the debug jit so that you could show up with Mono has this and more banner Gopal -- The difference between insanity and genius is measured by success
Selfbootstrapping compilers (Was: faq)
If memory serves me right, Markus Laire wrote: Miniparrot can then be used to build everything else, including full parrot, perl6, other parrot-supported languaged, etc.. This 2nd step might be e.g. Bytecode-compiled perl6-program which is simple enough to work with miniparrot. Please for heaven's sake don't write a perl6 compiler in perl6 ... It's *very* frustrating if I have to download version 1 to compile 1.1 and so on... (imagine compiling CVS head with a chain of older stuff) ... And even that is suspect when the fingerprinting and other stuff changes the binary packfile format ... (stuff like additional blobs or blocs have been discussed lately) I have seen instances where a fix to support feature x will need feature x to compile Dependency hellhole.. This is especially true as parrot doesn't have a fully functional reference implementation (like gcc using cc) to start a bootstrap . But yeah, I don't have any solutions either ... Gopal -- The difference between insanity and genius is measured by success
Re: Quick roadmap
If memory serves me right, Dan Sugalski wrote: Should be reasonably straightforward. Hopefully quick, too, as I'm pressed for time here. -- Hmm... Object frameworks ? ... (or is that shelved for the present ?) Gopal -- The difference between insanity and genius is measured by success
Re: branch dump
If memory serves me right, Dan Sugalski wrote: All you need to do is change the offset a bit to point to an opcode and you'll be fine. Hmm... you mean to say that a jump to a non-instruction is valid ? .. We've had the verifiability question hashed out ... but jump target validation is one of the simplest cases. This could a serious issue if Parrot starts using precompiled .pbc files (instead of the .pm model). Also it must be relatively simple to check for right ? ... A special option (for the sake of speed freaks ?) parrot -fverify hello.pbc ? Excuse my ignorance if such a thing already exists ... Gopal -- The difference between insanity and genius is measured by success
Re: branch dump
If memory serves me right, Dan Sugalski wrote: Sure. Or at least not forbidden. k ... that case, why bother verifying? Hmm wouldn't the JIT benifit from a pre knowledge of basic blocks and types or some information ? ... (I seem to think so ...). at runtime anyway. With a full scan of the bytecode, of course, and you'd need to figure where each and every instruction starts, which can be costly. Can't that be added onto the JIT'ing process ? ... viz during conversion ,check for jump targets ?.. I still have this assumption that JITs need to maintain some sort of basic block identification for peephole optimisations ?.. Or is that totally irrelvant for register VMs ? ... (this is the first register VM I have encountered...) option (for the sake of speed freaks ?) parrot -fverify hello.pbc ? No, the option'd be more that you enable verification rather than disable it. Speed is the default. Yup I meant just that not -noverify' , but -verify :-)... So, Parrot is more secure than perl is ? (that being your benchmark). Gopal -- The difference between insanity and genius is measured by success
Re: Draft sketch of bytecode generation
If memory serves me right, Dan Sugalski wrote: (Parrot bytecode is inherently unverifiable as well, at least in the general case, which exacerbates the problem) Hmm... Why ? ... Loose typing ? Or does it just become an undecidability problem ?... Gopal -- The difference between insanity and genius is measured by success
Re: Looking for a Parrot contact person
If memory serves me right, Leopold Toetsch wrote: The changes are 99.9% internal - all (parrot + perl6) tests are running during these changes. Hmm... a .pbc I assembled last week refused to run today ... which was really surprising for me .. `PackFile_unpack: Bytecode not valid for this interpreter: version mismatch' So what I had been wondering was , while using a statically typed language like C# , you need to lookup the method signatures and similar things at compiletime ... In general, the libs-metadat can be read to provide this info , but if such changes as above quoted occur ... we might be into a bumpy road .. /me wants to be able to cscc -mpvm -lSystem 1.cs for pnet, which would mean that we need an image loader for parrot as well .. I hope I make myself clear. what changes do actually break e.g. C#, but are totally ok for us, because they are termed internal. Hmm I know pm_nodes.tc is in CVS , but the design issue of classes is still holding rhys back (or I think so)... So I also don't really know the breaking points we might have .. I can include these tests prior to committing non bugfixe like changes. Well not today or tomorrow ... Pnet has a nice testsuite (cscctest) to test the compiler ... And pnet cvs might not be that much a hassle to compile test ... So this is almost exactly what I had in mind... But remember, we still have to hammer out the PMCodeGen nodes to let you test the stuff ... :-) I think Dan is the coordinator here. Though if you can spec your needs towards opcodes or other issues, more people could consider, how to efficiently implement these. /me knows Dan is the Designer and we might be able to reuse or slightly readjust the existing opcodes ... That would mean that either we study parrot from end to end or we ask someone with experience for advice ... (guess which I'll prefer :-) As _currently_ I seem to be the one, doing ~80% changes in CVS, I probably should take that part - though I really don't know the demands of your project. Ok, so that would mean the you and rhys should be the people on top... I think that needs the hands of the two designers and the code demons.. (/me is an implementor , not a designer ) This is a good thing IMHO, because parrot will work for different HLs in an optimized way. Yes ... from a quick glance my expr_compiler code which generates imcc and il code from arithmetic expressions showed that parrot was quite faster than pnet (which is unsurprising as pnet is a souped up interpreter). As you seem to use imcc now as the target assemble language, any thoughts towards this are welcome too. Nice language ... It solves the eternal problem of register spills that plague the standard register based VMs . Than means no more no linear scan, graph coloring is better arguments !! ... That's one of the reasons we're so eager to do it .. Because we can almost generate subexpression code without a care for spillovers and let imcc optimise it later.. Theoretically we need only as much temporary variables as (max_stack_size * max_var_types) .. with $typen being the stack top and all that .. I did download treecc and I had a brief look at it. Yes - it looks like this is the tool perl6 might need, for going to be native C compiled. Hmm... it's going to be native compiled ? ... from my experience , trying to *read* gcc code is more difficult that writing treecc code ... Current thoughts AFAIK are towards a self bootstrapping miniparrot, compiling the perl written perl6 compiler - but as said AFAIK and far future still ... print eval(all(future_dev_paths)) ~ NL; That would mean reuse of the exisiting code ... or maybe you should try your hand at a perl generator for treecc (has gens for c,c++,java c#).. Gopal -- The difference between insanity and genius is measured by success
Re: C# and Parrot (dotgnu meeting)
If memory serves me right, Leon Brocard wrote: It looks like the DotGNU weekly IRC meeting will be discussing Parrot. Could be interesting: http://www.dotgnu.org/pipermail/developers/2002-October/008345.html A condensed summary of the IRC meetings have been posted as :- http://www.dotgnu.org/pipermail/developers/2002-October/008380.html. Also the full logs are available from http://ajmitch.dhis.org/dotgnu/ Gopal ps: here's my hello world to parrot , a small example compiler that does IL and *now* parrot. http://symonds.net/~gopalv82/code/expr_compiler.tgz Check out the treecc AST operation management . -- The difference between insanity and genius is measured by success
Re: C# and Parrot
If memory serves me right, Bryan C. Warnock wrote: It looks like we're going to need 8,16,32,64 bit types... Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe for floating point numbers? IL (Ecma-335) -- 134.1.1 Floating Point 14 The floating point feature set consists of the user-visible floating-point data types float32 and float64, and 15 support for an internal representation of floating-point numbers. Float32 -- Single Float64 -- Double And,IIRC the same for JVM as well ?. Are we still targeting a middle ground for C? (Enough to be able to parse and handle structs natively, and possibly even make calls natively?) Hmm... would be thinking of something like PInvoke in C# ? (viz a lot like JNI, but marshalls/unmarshalls args automatically, and we've managed to wrap parts of X11 with it). Or are you thinking about compiling C to Parrot ? Dan : Consider it both mildly interesting and mildly bemusing :) Gopal -- The difference between insanity and genius is measured by success
