Re: [perl #34258] [TODO] Here documents for PIR
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Hi, > in the near, or far, future there will be test scripts and compiler > input in PIR. For that it would be nice, if long text doesn't have to > be crammed into a single line. > So some kind of HERE document syntax is needed for PIR. Suggestions > for syntax elements are welcome. '<<' is already taken for the left > shift operator. Yeah. I came to the same conclusion, while hacking the Z translator. While the syntax extension isn't really necessary, it can produce much more readable code. WRT syntax: $S0 = <<_EOT_ ... _EOT_ will work, because the token "<<_EOT_" is longer then the token "<<". The only thing that will stop working is: .local int _EOT_ $I0 = $I1 <<_EOT_ # space needed then Not much of a problem. We don't need and don't support nested HERE docs, so one fix-defined "<<_EOT_" or some such will do it. > CU, Bernhard leo
Re: How to check an attribute's existence
Cory Spencer <[EMAIL PROTECTED]> wrote: > Is is possible to check to see whether an attribute exists on a given > object, or at least catch an exception if it doesn't? I've tried to set > up an exception handler, but Parrot exits without anything being caught. Not yet. C throws currently an uncatchable internal exception. leo
Re: [perl #34258] [TODO] Here documents for PIR
MrJoltCola <[EMAIL PROTECTED]> wrote: > I feel that this feature is for higher level languages. [ snip ] > ... PIR is for compilers, not people, PIR is foremost Parrot's primary assembly language. If it were for compiles only, it wouldn't have needed "a = b + c" in the first place, the "add" opcode is doing the same. PIR has nice constructs for function and method calls. I don't see any reason, why people shouldn't write PIR code directly. A HERE document syntax allows to write more readable code. leo
[RESENT] (was: [perl #32989] Problem in linux ppc)
Leopold Toetsch <[EMAIL PROTECTED]> wrote: I'm still waiting for confirmation that the recipe below works for ppc-linux. Thanks, leo >> jitcapable=1, jitarchname=ppc-linux, > I've now tried to fix that too long lasting problem. > 1) attach the patch below > 2) mv config/gen/platform/darwin/asm.s jit/ppc > 3) perl Configure.pl --nomanicheck # or fix MANIFEST > This might cause trouble for ppc-aix, because the asm function is > included via a different mechanism too. > Tested on OS X only. If that works, cleanup (MANIFEST, aix) can follow. > leo > --- parrot/config/auto/jit.pl Wed Feb 2 13:23:59 2005 > +++ parrot-leo/config/auto/jit.pl Mon Feb 14 18:02:32 2005 > @@ -79,10 +79,13 @@ > } >} > - if (-e "config/gen/platform/$cpuarch.s") { > -copy_if_diff("config/gen/platform/$cpuarch.s", "asmfun.s"); > - > -Configure::Data->set(asmfun_o => 'asmfun$(O)'); > + if (-e "jit/$cpuarch/$jitarchname.s") { > +copy_if_diff("jit/$cpuarch/$jitarchname.s", "src/asmfun.s"); > +Configure::Data->set(asmfun_o => 'src/asmfun$(O)'); > + } > + elsif (-e "jit/$cpuarch/asm.s") { > +copy_if_diff("jit/$cpuarch/asm.s", "src/asmfun.s"); > +Configure::Data->set(asmfun_o => 'src/asmfun$(O)'); >} else { > Configure::Data->set(asmfun_o => ''); >}
Re: [perl #34258] [TODO] Here documents for PIR
MrJoltCola wrote: > This should actually be titled "Where are all the compilers?" The compilers will come! Loads of people, myself included, are quietly working away on compilers that target IMC. It takes time for people to discover and adopt new platforms - especially when you are so modest about Parrot. The FAQ says: "Parrot is in the early phases of its implementation. The primary way to use Parrot is to write Parrot assembly code" when it could say something like: "Although parrot is not yet complete, and indeed the design is still being refined, it already offers an elegant, powerful, feature-rich, solidly-designed (though poorly documented) environment that makes it amazingly easy to implement a wide range of scripting languages. The primary way to use parrot is to generate code for its intermediate language compiler (IMC) which handles all of the following things (and more) for you: numbers, bignums, objects, multiple inheritance, closures, garbage collection, strings, polymorphic feature dispatch, regular expressions, exception handling, and more!" > ... here documents ... I don't care strongly either way about here-documents, and they're not going to make-or-break parrot. Lots of folks like to use here-documents, and lots of folks get by just fine using languages that don't support anything like here-documents. (Would I would like, though, is for the ".include" macro to find .../runtime/parrot/include like it says it does in the documentation :-) But these things are mere details, minor bumps along the road. > Years after I dumped much work into Parrot, I've seen no progress or support > from other language camps (Python, Scheme) and Perl 6 seems to be such a > daunting goal to implement, I'm afraid we won't a full, commercial-free > implementation for years... It would be ironic indeed if the standard Perl 6 implementation ended up being written in Haskell! But Melvin's work on IMC is one of the core things that will ensure Parrot's success. Many people wouldn't want to manually generate code that satisfies the parrot assembly language calling conventions, but they can cope with generating $P1."foo"($P2). > . Or were we so slow with Perl 6 that everyone had time to swallow the .NET > pill? Naaah! Parrot is the scripting platform for the next few decades, so it doesn't matter if it takes a few years for it to catch on. Sorry that I can't help out more myself - I'm not fluent in either C or Perl (I'm getting pretty good at IMC though!). But I'll at least help out bringing the compilers that Melvin craves. Regards, Roger -- Roger Browne <[EMAIL PROTECTED]>
Re: [perl #34258] [TODO] Here documents for PIR
At 03:21 AM 2/25/2005, Leopold Toetsch wrote: MrJoltCola <[EMAIL PROTECTED]> wrote: > I feel that this feature is for higher level languages. [ snip ] > ... PIR is for compilers, not people, PIR is foremost Parrot's primary assembly language. If it were for compiles only, it wouldn't have needed "a = b + c" in the first place, the "add" opcode is doing the same. It filled a need at the time I wrote it, because there was pretty much nothing else to write code in except PASM and Jako. It was supposed to be a thin layer (register allocation and instruction choosing and subs) over PASM. Nowadays we have a hoard of little toy compilers. PIR has nice constructs for function and method calls. I don't see any reason, why people shouldn't write PIR code directly. A HERE document syntax allows to write more readable code. ...and adds another straw to the Camel's back of IMCC maintainability ...and encourages people to stay complacent and keep writing PIR code by hand, which was the main point of my note. -Melvin
Re: [perl #34258] [TODO] Here documents for PIR
MrJoltCola wrote: At 03:21 AM 2/25/2005, Leopold Toetsch wrote: MrJoltCola <[EMAIL PROTECTED]> wrote: > I feel that this feature is for higher level languages. [ snip ] > ... PIR is for compilers, not people, My impression was that the target for compilers should be a yet non-existent abstract syntax tree. Though I'm somewhat confused about the distinction between parse trees and AST. PIR and PAST could be considered as being just some languages. Why don't they take the some route, and generate an AST that gets compiled into PBC? However most compilers I have seen so far are generating PIR and go from there. PIR is foremost Parrot's primary assembly language. If it were for compiles only, it wouldn't have needed "a = b + c" in the first place, the "add" opcode is doing the same. It filled a need at the time I wrote it, because there was pretty much nothing else to write code in except PASM and Jako. It was supposed to be a thin layer (register allocation and instruction choosing and subs) over PASM. It is certainly possible to write code in PIR. But it is even more certain that this is no fun. Adding HERE documents remedies an immediate need, especially for playing with compilers and test scripts. > Nowadays we have a hoard of little toy compilers. Which language of that hoard should be promoted to become THE standard language for writing test scripts and the Parrot standard library? PIR is too hard on people, and a scripting language like Ruby, Perl or Python is propably to hard on Parrot. It propably shouldn't a newly invented language either, because all language designers are having fun with designing Perl6. How about ECMAScript? It has an specification, it has objects and no pointers. CU, Bernhard -- ** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Q: about Parrot assembly code
Hi, I just came across Parrot the other day, so some of you might think I may have been living under a rock for a little while (and you might not be so wrong either - lol), so please excuse me if I am way out in left field on this topic, but I have a slightly upside down interest in Parrot asm at the moment. One research project of mine has taken me on a quest to be able to "verify" or do some kind of assurance testing on binary objects for security purposes. Not to "reverse engineer", but to understand the deltas between releases in some executables and look for logic like back doors etc. Because of the plethora of CPU processors in this world this is a very difficult task and there are no tools that I have seen that do much better than disassemble the specific machine code (IDA Pro with BinDiff being one good combo), and all those other tools are pretty much incompatible due to the specific nature of each given processor. I need something better than asm to analyze, but not a "decompiler" (e.g. boomerang) per se, since I have no intention of changing any code. A "virtual processor" would work well because all visual tools would only have to understand one language. Assuming for the moment that one could build a Parrot asm language or bytecode to logical directed graph translator/analyzer, and create an interactive IDE used to explore and understand the underlying application; just how compatible is the virtual Parrot asm CPU to the many "real world" CPU's out there? Are there constructs that could not be logically mapped from other CPU's into Parrot? Does Parrot assume/use many high level constructs not found in real processors? Some CPU translations, like from CISC to RISC, are clearly easier than the reverse, but other types would prove much more difficult, like those with specialized register windows and DSP vector processors. Understanding what can and can not be translated to and from the virtual Parrot CPU would be the key to my looking at this possibility any deeper, but I could also forsee the possibility of some future type of IDE tools being used to create and debug other applications visually through Parrot as an intermediary between languages and runtime bytecode. Translation of programs (e.g. Perl<=>Python<=>.Net) would also be possible. Any thoughts from the real Parrot asm experts out there? Thanks! -- Steve Coleman Johns Hopkins University / Applied Physics Laboratory
Re: [perl #34258] [TODO] Here documents for PIR
At 11:48 AM 2/25/2005, Bernhard Schmalhofer wrote: MrJoltCola wrote: At 03:21 AM 2/25/2005, Leopold Toetsch wrote: MrJoltCola <[EMAIL PROTECTED]> wrote: > I feel that this feature is for higher level languages. [ snip ] > ... PIR is for compilers, not people, My impression was that the target for compilers should be a yet non-existent abstract syntax tree. Though I'm somewhat confused about the distinction between parse trees and AST. PIR and PAST could be considered as being just some languages. Why don't they take the some route, and generate an AST that gets compiled into PBC? However most compilers I have seen so far are generating PIR and go from there. Text mode IR is easier to debug with the naked eye than an AST. ASTs are great if you have supporting tools to browse the tree, dump things out and translate things back to IR. Virtually all compilers start with an IR and mature into AST usage, but many successful compilers are built with completely separate layers. See Muchnicks's work at Sun Microsystems. He has been the main influence on me as a compiler writer. PIR is foremost Parrot's primary assembly language. If it were for compiles only, it wouldn't have needed "a = b + c" in the first place, the "add" opcode is doing the same. It filled a need at the time I wrote it, because there was pretty much nothing else to write code in except PASM and Jako. It was supposed to be a thin layer (register allocation and instruction choosing and subs) over PASM. It is certainly possible to write code in PIR. But it is even more certain that this is no fun. Adding HERE documents remedies an immediate need, especially for playing with compilers and test scripts. I agree. Why not write a pre-processor that will handles things like this and then merge them forwards towards a front-end compiler rather than backwards into the mess of IMCC? Trust me, I know the IMCC code, and it is BAD BAD BAD. And I fully share the blame with Leo and Angel, bless their hearts. :) > Nowadays we have a hoard of little toy compilers. Which language of that hoard should be promoted to become THE standard language for writing test scripts and the Parrot standard library? PIR is too hard on people, and a scripting language like Ruby, Perl or Python is propably to hard on Parrot. It propably shouldn't a newly invented language either, because all language designers are having fun with designing Perl6. You echo my feelings, PIR is too hard on people, and I feel that Parrot's growth suffers for it, not because of PIR, but because that is all we use. I'm appalled that 3 years after I submitted IMCC to the project, everyone is still writing in PIR. Parrot need's its own version of "C" or "C#" to empower more people to contribute. If every new feature for Parrot is thought of in terms of PIR & IMCC, then IMCC will just become more of a tangled mess that nobody wants to touch, and high-level development will continue to drag as it has for years. How about ECMAScript? It has an specification, it has objects and no pointers. No complaints from me, I don't vote much anyway, but I have strong feelings regarding this project. The mixing of the VM team and the compiler team is a mistake. It is a problem for commercial development, much less open-source. One pumpking making decisions for such a wide scope doesn't leave much room for alternate points of view and unimpeded movement. This is why I urged Dan long ago to form a parrot-compilers list and split the project into separate decision making teams. Speaking of Dan, where is he? -Melvin
Calling C/C++ library routines
Hello, I've been developing a compiler that will target Parrot for the last couple of months. I have a question. I've only been reading the list for a short time (1 - 1 1/2 months). I was reading some of the past articles, but there's just so many of them that I figure I might as well just ask the question directly. Is there now, or will there be in the future, any way to call C/C++ library routines from within Parrot? For example, a mysql, pcre or libcurl library. Either static or dynamic. I haven't actually program using either PASM or PIR(?) yet, since I'm still working on the details of my compiler, such as the grammar, etc; but I'm curious if this feature is available as this is something I have to take into consideration right now. Thanks $vlad.f()
Re: Q: about Parrot assembly code
At 12:57 PM 2/25/2005, Steve Coleman wrote: constructs that could not be logically mapped from other CPU's into Parrot? Does Parrot assume/use many high level constructs not found in real processors? Some CPU translations, like from CISC to RISC, are clearly easier than the reverse, but other types would prove much more difficult, like those with specialized register windows and DSP vector processors. I doubt there is much that could not be mapped to Parrot, but Parrot does things that would be impossible to map directly back to a CPU. Parrot is a mix of low, medium and high level instructions. We have ops that are jitted to a single instruction or two on a CPU, but we have many more ops that are large routines that would have to be translated to an API call requiring run-time environment support, continuations, co-routines, various other odd things which require garbage collectable stacks and execution contexts. You should be able to easily map your external APIs to Parrot. It has a native interface, so for example if you have an Oracle app that uses libclntsh.so, you'll simply need to translate any calls to the Parrot Native Interface by generating the appropriate stub for the Parrot side. For extended processor functions, you'd need to implement them or JIT them. It may be simpler to support JIT-only for your project. When you talk about DSP processors, you are out of my range. Register windows ala Sparc could be implemented easily, and has been discussed periodically, though we chose a different calling convention. Regarding mapping from Parrot, you'd need to build a libparrot and link to your new environment for dispatch of those things that don't translate. I'm not sure why you'd want to do this, though. We don't have any application base to speak of. :) Understanding what can and can not be translated to and from the virtual Parrot CPU would be the key to my looking at this possibility any deeper, but I could also forsee the possibility of some future type of IDE tools being used to create and debug other applications visually through Parrot as an intermediary between languages and runtime bytecode. Translation of programs (e.g. Perl<=>Python<=>.Net) would also be possible. There has been some successful work done by various people if you dig back through the archives. I was able to successfully translate some Java to Parrot, as did someone else; who it was, I forget. Someone else has been playing with Z-machine lately I think. Cheers, -Melvin
Re: Calling C/C++ library routines
At 01:27 PM 2/25/2005, vlad florentino wrote: Is there now, or will there be in the future, any way to call C/C++ library routines from within Parrot? For example, a mysql, pcre or libcurl library. Either static or dynamic. C yes. C shares objects are dynamically loadable by Parrot. C++? Not directly, you'll need to wrap any C++ APIs in "extern C" stubs to get at them from Parrot and make sure you stuff any object pointers into a PMC. It has been done, an example is the C++ Qt Toolkit. -Melvin
Fwd: Calling C/C++ library routines
-- Forwarded message -- From: vlad florentino <[EMAIL PROTECTED]> Date: Fri, 25 Feb 2005 13:56:33 -0500 Subject: Re: Calling C/C++ library routines To: MrJoltCola <[EMAIL PROTECTED]> On Fri, 25 Feb 2005 13:40:15 -0500, MrJoltCola <[EMAIL PROTECTED]> wrote: > At 01:27 PM 2/25/2005, vlad florentino wrote: > >Is there now, or will there be in the future, any way to call C/C++ > >library routines from within Parrot? For example, a mysql, pcre or > >libcurl library. Either static or dynamic. > > C yes. C shares objects are dynamically loadable by Parrot. > C++? Not directly, you'll need to wrap any C++ APIs in "extern C" stubs > to get at them from Parrot and make sure you stuff any object pointers into > a PMC. It has been done, an example is the C++ Qt Toolkit. > > -Melvin > > Wow, that's great! Are there any examples showing how one can call C routines in Parrot? $vlad.f()
Re: Calling C/C++ library routines
http://cvs.perl.org/viewcvs/cvs-public/parrot/examples/pni/ has examples for QT, sdl, and the win32 API. Regards. vlad florentino writes: Wow, that's great! Are there any examples showing how one can call C routines in Parrot? $vlad.f()
Re: Calling C/C++ library routines
On Fri, 2005-02-25 at 14:18 -0500, Will Coleda wrote: > http://cvs.perl.org/viewcvs/cvs-public/parrot/examples/pni/ > > has examples for QT, sdl, and the win32 API. The actual NCI stuff (for SDL bindings, at least) is in: http://cvs.perl.org/viewcvs/cvs-public/parrot/runtime/parrot/library/ -- c
RE: [perl #34258] [TODO] Here documents for PIR
Melvin wrote: > > Parrot need's its own version of "C" or "C#" to empower more people > to contribute. If every new feature for Parrot is thought of in > terms of PIR & IMCC, then IMCC will just become more of a tangled > mess that nobody wants to touch, and high-level development will > continue to drag as it has for years. C scripting language implementations S-lang: http://www.s-lang.org/index.html seeR: http://przemekp.prv.pl/seer/ EiC: http://eic.sourceforge.net/ CSL: http://csl.sourceforge.net/ CINT: http://root.cern.ch/root/Cint.html CH: http://www.softintegration.com/ -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: [RESENT] (was: [perl #32989] Problem in linux ppc)
On Fri, 2005-02-25 at 12:31 +0100, Leopold Toetsch wrote: > I'm still waiting for confirmation that the recipe below works for > ppc-linux. Nope, the assembler here doesn't understand the code. Here's what worked for me. -- c #define PPC_JIT_GP_REGISTER_SAVE_SPACE (4*19) ;; This macro would generate the below asm, but requires using 'cc -c' ;; rather than 'as' as the assembler (so that the preprocessor runs), ;; and this is not currently configurable in the Parrot makefiles .macro RESTORE_NONVOLATILE_FLOATS lfdf14, -PPC_JIT_GP_REGISTER_SAVE_SPACE-1*8(r1) lfdf15, -PPC_JIT_GP_REGISTER_SAVE_SPACE-2*8(r1) lfdf16, -PPC_JIT_GP_REGISTER_SAVE_SPACE-3*8(r1) lfdf17, -PPC_JIT_GP_REGISTER_SAVE_SPACE-4*8(r1) lfdf18, -PPC_JIT_GP_REGISTER_SAVE_SPACE-5*8(r1) lfdf19, -PPC_JIT_GP_REGISTER_SAVE_SPACE-6*8(r1) lfdf20, -PPC_JIT_GP_REGISTER_SAVE_SPACE-7*8(r1) lfdf21, -PPC_JIT_GP_REGISTER_SAVE_SPACE-8*8(r1) lfdf22, -PPC_JIT_GP_REGISTER_SAVE_SPACE-9*8(r1) lfdf23, -PPC_JIT_GP_REGISTER_SAVE_SPACE-10*8(r1) lfdf24, -PPC_JIT_GP_REGISTER_SAVE_SPACE-11*8(r1) lfdf25, -PPC_JIT_GP_REGISTER_SAVE_SPACE-12*8(r1) lfdf26, -PPC_JIT_GP_REGISTER_SAVE_SPACE-13*8(r1) lfdf27, -PPC_JIT_GP_REGISTER_SAVE_SPACE-14*8(r1) lfdf28, -PPC_JIT_GP_REGISTER_SAVE_SPACE-15*8(r1) lfdf29, -PPC_JIT_GP_REGISTER_SAVE_SPACE-16*8(r1) lfdf30, -PPC_JIT_GP_REGISTER_SAVE_SPACE-17*8(r1) lfdf31, -PPC_JIT_GP_REGISTER_SAVE_SPACE-18*8(r1) .endmacro .text .align 12 ; vm page aligned .globl _Parrot_ppc_jit_restore_nonvolatile_registers _Parrot_ppc_jit_restore_nonvolatile_registers: lfd f14,-84(r1) lfd f15,-92(r1) lfd f16,-100(r1) lfd f17,-108(r1) lfd f18,-116(r1) lfd f19,-124(r1) lfd f20,-132(r1) lfd f21,-140(r1) lfd f22,-148(r1) lfd f23,-156(r1) lfd f24,-164(r1) lfd f25,-172(r1) lfd f26,-180(r1) lfd f27,-188(r1) lfd f28,-196(r1) lfd f29,-204(r1) lfd f30,-212(r1) lfd f31,-220(r1) blr
Re: [RESENT] (was: [perl #32989] Problem in linux ppc)
On Fri, 2005-02-25 at 13:18 -0800, chromatic wrote: > Nope, the assembler here doesn't understand the code. Here's what > worked for me. Ignore that attachment, it's wrong. Here's the right one. -- c .text .align 12 .globl Parrot_ppc_jit_restore_nonvolatile_registers Parrot_ppc_jit_restore_nonvolatile_registers: lfd 14, -84(1) lfd 15, -92(1) lfd 16, -100(1) lfd 17, -108(1) lfd 18, -116(1) lfd 19, -124(1) lfd 20, -132(1) lfd 21, -140(1) lfd 22, -148(1) lfd 23, -156(1) lfd 24, -164(1) lfd 25, -172(1) lfd 26, -180(1) lfd 27, -188(1) lfd 28, -196(1) lfd 29, -204(1) lfd 30, -212(1) lfd 31, -220(1) blr
Re: Q: about Parrot assembly code
MrJoltCola wrote: I doubt there is much that could not be mapped to Parrot, but Parrot does things that would be impossible to map directly back to a CPU. Currently I am only thinking of just a CPU X to Parrot asm translation, not the reverse, and this is just an attempt to get to a consolidated Virtual CPU (VPU?) model, and a single language syntax or state machine to deal with. All tools from that point on would work on a common model of the same virtual cpu. I could pick any virtual CPU and that would be Ok because it would not have to be run anywhere to be able to analyse structure and purpose, but Parrot would then have the potential benifit of having additional tools developed for understanding program structure. After all, why build something nobody else could use? Well it seemed like a good idea at the time, but as I feared the Parrot virtual CPU is highly slanted towards a very different goal. I'm not sure why you'd want to do this, though. We don't have any application base to speak of. :) I'm not looking for any Parrot apps to run, but the extension of that same capability could eventually lead to extra debugging and bitecode runtime support, but thats not my primary aim. The more near-term benifit might have been a set of "anything to Parrot" translators, which in theory could then be used to convert all your favorite binary applications to your favorite new runtime VM. Then you could have lots of applications! (lol) This part of course was meant as a joke, but then Parrot itself started as a joke did it not? In any case I will be interested to see your project move forward and become a reality. Perl has been a wonderful language, for so many purposes, and I believe with this project in the works there will be a lot more of that to come in the future as well. -- Steve Coleman Johns Hopkins University / Applied Physics Laboratory