Re: [perl #34258] [TODO] Here documents for PIR

2005-02-25 Thread Leopold Toetsch
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

2005-02-25 Thread Leopold Toetsch
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

2005-02-25 Thread Leopold Toetsch
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)

2005-02-25 Thread Leopold Toetsch
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

2005-02-25 Thread Roger Browne
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

2005-02-25 Thread MrJoltCola
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

2005-02-25 Thread Bernhard Schmalhofer
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

2005-02-25 Thread Steve Coleman
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

2005-02-25 Thread MrJoltCola
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

2005-02-25 Thread vlad florentino
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

2005-02-25 Thread MrJoltCola
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

2005-02-25 Thread MrJoltCola
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

2005-02-25 Thread vlad florentino
-- 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

2005-02-25 Thread Will Coleda
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

2005-02-25 Thread chromatic
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

2005-02-25 Thread Garrett Goebel
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)

2005-02-25 Thread chromatic
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)

2005-02-25 Thread chromatic
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

2005-02-25 Thread Steve Coleman
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