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?
From: Dan Sugalski [mailto:d...@sidhe.org]
Sent: Monday, March 22, 2004 7:56 AM
To: Gerald E Butler; perl6-i...@perl.org
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:
> 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
> 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.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org 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.
Fwiw I seem to remember palyign with an interpreted C. I can't remember
if or how they solved such problems.
may or may not ahve been the one I noodled with.
With the caveat that I know nothing about gcc's internals, it seems
at least reasonable. :)
> 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
This requirement probably means that Fortran is a non-starter, as a
number of its features (equivalence, common blocks) do rely on a specific
layout of variables in memory.
If I recall correctly, GCC supports Haskell, which is an ideal language
Haskell is a functional language (like Scheme or ML), thus it needs
support for things like closures and continuations. This also means
that having an interpreter to provide higher level feature like
memoizing thunks is very useful. Haskell does not provide direct memory
manipulation (which is the problem with C). It also has some nifty
stuff with lazy evaluation that would not be too difficult to wrap in a pmc.
So there in a nut shell is why Haskell would play well with Parrot. If
you wanted more specifics about Haskell itself, I would suggest poking
> If I recall correctly, GCC supports Haskell, which is an ideal
> language for Parrot.
GCC doesn't support Haskell -- perhaps the compiler you're thinking of
is GHC? (Glasgow Haskell Compiler).
I'm starting to look at implementing a Haskell to Parrot compiler, but
don't hold your breath :).
% Andre Pang : trust.in.love.to.save
I would greatly support adding a Haskell compiler and would be willing
to lend a hand if you wanted one.
> I could be getting things mixed up here, but I thought I read that GHC
> (Glasgow Haskell Compiler) is part of GCC (GNU Compiler Collection).
> Although I might be misreading this paper slightly
GHC can optionally use GCC as a back-end code generator; i.e. it can
output Haskell as C code, which is then compiled by GCC.
| If I recall correctly, GCC supports Haskell, which is an ideal
| language for Parrot.
That might probably be the case, but we don't have it in the FSF
release and I don't recall we have any mention of Haskell in the
section of various front-ends for GCC we know about.
I do know, however, that we have some support for Mercury
(that is not directly contained in FSF GCC but, occasionally we have
patches that arranges things for it).