OK, I think I'm starting to get a better picture of what needs to happen. Does
this sound more reasonable?
Java, C#, Fortran(???), (Managed???)C++, (Other languages with
appropriate non-direct memory access)
==> GCC Parser
==> Parse Tree
==> Enhanced RTL (where enhanced means semantics preserving RTL rather
than the current machine oriented RTL)
==> ERTL (Enhanced RTL) -> PARROT ByteCode
==> PARROT Optimizer
==> PARROT Runtime (w/ JIT)
The important point is that the starting language must have semantics which
treat variables, object, etc. as abstract entities to be manipulated not
*memory locations* to be accessed arbitrarily. Then, the parse stage must spit
out ERTL which preserves the semantics (in as general a fashion as possible)
so that we can map appropriately to PARROT. Things like:
1. Function/Sub-Routine/Method Call
2. Object Creation/Destruction/Ref/De-Ref (where a ref *MUST NOT* be
thought of as a pointer to memory, but, rather and abstract reg not unlike C++
Ref, Perl Ref, etc, etc)
3. Looping and other Control Structures (Possibly???)
4. Function/Sub-Routine/Method Creation
5. Class Declaration (Creation)
6. Other similar things (suggestions welcome)
So, then the task becomes as follows:
1. Define a new ERTL to represent these higher-level constructs
2. Create Parser options in GCC to spit out the ERTL rather than RTL
3. Create a Machine Description (Back-End) for GCC to map ERTL --->
PARROT Byte Code (or ICCM/PASM)
4. Task basically done (except for any type of linking semantics that
might need implemented)
Does this sound like a fair assessment of the situation?
-----Original Message-----
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 7:56 AM
To: Gerald E Butler; [EMAIL PROTECTED]
Subject: Re: GCC for PARROT (GCC Compiling itself to PARROT, then
compiling all supported languages to PARROT from PARROT)?!?!
At 11:33 AM -0500 3/20/04, Gerald E Butler wrote:
>Hello all,
>
> I've been investigating the possibility of creating a MACHINE
>DESCRIPTION (aka BACK-END) for GCC to target PARROT. My thinking is
>this: If a satisfactory GCC back-end targeting PARROT is created -and-
>PARROT is efficient enough (which from reading the documentation thus
>far produced seems like it is an inevitable conclusion) then GCC could
>compile itself to PARROT byte-code giving PARROT (and the whole open
>source community) a PARROT self-host compiler which compiles multiple
>languages (C#, C++, C, Pascal, Objective-C, Java, etc, etc, etc) to the
>PARROT runtime.
>
> Is a complete non-starter, or is this something which has
>possibilities? Please give your expert opinions.
While I think you may run into some issues (James pointed some out
already) I also think it's worth looking at in some more depth
anyway. It may be problematic for some languages, but GCC compiles a
lot and I don't see any reason why we shouldn't be OK with, say,
FORTRAN or java.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
The information contained in this e-mail message is privileged and/or
confidential and is intended only for the use of the individual or entity
named above. If the reader of this message is not the intended recipient,
or the employee or agent responsible to deliver it to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please immediately notify us by telephone
(330-668-5000), and destroy the original message. Thank you.
