GCC for PARROT (GCC Compiling itself to PARROT, then compilin g all supported languages to PARROT from PARROT)?!?!

2 views
Skip to first unread message

Gerald Butler

unread,
Mar 22, 2004, 9:54:56 AM3/22/04
to Dan Sugalski, Gerald E Butler, perl6-i...@perl.org, Toth, Frank
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: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:
>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
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.


Simon Wistow

unread,
Mar 22, 2004, 10:13:16 AM3/22/04
to Butler, Gerald, perl6-i...@perl.org
On Mon, Mar 22, 2004 at 09:54:56AM -0500, Butler, Gerald said:
> 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:

Fwiw I seem to remember palyign with an interpreted C. I can't remember
if or how they solved such problems.

http://root.cern.ch/root/Cint.html

may or may not ahve been the one I noodled with.


Dan Sugalski

unread,
Mar 22, 2004, 11:04:45 AM3/22/04
to Butler, Gerald, Gerald E Butler, perl6-i...@perl.org, Toth, Frank
At 9:54 AM -0500 3/22/04, Butler, Gerald wrote:
>
>OK, I think I'm starting to get a better picture of what needs to happen. Does
>this sound more reasonable?

With the caveat that I know nothing about gcc's internals, it seems
at least reasonable. :)

Simon Glover

unread,
Mar 22, 2004, 2:08:40 PM3/22/04
to Butler, Gerald, perl6-i...@perl.org

On Mon, 22 Mar 2004, Butler, Gerald wrote:

> 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.

Simon


Matt Fowles

unread,
Mar 22, 2004, 2:23:32 PM3/22/04
to Simon Glover, Butler, Gerald, perl6-i...@perl.org
All~

If I recall correctly, GCC supports Haskell, which is an ideal language
for Parrot.

Matt

Gerald E Butler

unread,
Mar 22, 2004, 6:02:42 PM3/22/04
to Matt_...@softhome.net, Simon Glover, Butler, Gerald, perl6-i...@perl.org
Could you please give a little more insight on Haskell and why it
is/would be so good? I've never heard of it.

Matt Fowles

unread,
Mar 22, 2004, 7:51:25 PM3/22/04
to Gerald E Butler, Simon Glover, Butler, Gerald, perl6-i...@perl.org
I can try, although I do not know Haskell very well.

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
around online.

Matt

oz...@algorithm.com.au

unread,
Mar 22, 2004, 8:09:09 PM3/22/04
to Matt_...@softhome.net, sc...@amnh.org, gerald...@jewels.com, perl6-i...@perl.org
On 23/03/2004, at 6:23 AM, Matt Fowles wrote:

> 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

Matt Fowles

unread,
Mar 22, 2004, 8:24:32 PM3/22/04
to oz...@algorithm.com.au, sc...@amnh.org, gerald...@jewels.com, perl6-i...@perl.org
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

http://home.in.tum.de/~baueran/thesis/

I would greatly support adding a Haskell compiler and would be willing
to lend a hand if you wanted one.

Matt

oz...@algorithm.com.au

unread,
Mar 22, 2004, 9:12:40 PM3/22/04
to Matt_...@softhome.net, perl6-i...@perl.org, gerald...@jewels.com, sc...@amnh.org
On 23/03/2004, at 12:24 PM, Matt Fowles wrote:

> 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
>
> http://home.in.tum.de/~baueran/thesis/

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.

Gabriel Dos Reis

unread,
Mar 23, 2004, 5:59:47 AM3/23/04
to Matt_...@softhome.net, Simon Glover, Butler, Gerald, perl6-i...@perl.org
Matt Fowles <Matt_...@softhome.net> writes:

| All~
|
| 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).

http://www.cs.mu.oz.au/research/mercury/download/gcc-backend.html

-- Gaby

Reply all
Reply to author
Forward
0 new messages