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

[Gerald Butler]

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]

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]

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]

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]

All~

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

Matt

[Gerald E Butler]

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]

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]

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]

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]

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]

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