On Sun, 2004-03-21 at 04:49, James Mastros wrote:
> 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
> > PARROT runtime.
>
> At first glance, this looks like a good thing to do. After all, Parrot
> was made a register machine, instead of a stack machine, to be able to
> leverage the existing art with reference to real machines, which are
> register machines, not stack machines.
>
> So what's the problem?
>
> In a word: Memory. GCC expects the machine to be more or less like a
> real machine. This means, in no small part, that it has a large amount
> of memory, accessible by getting a pointer to it, which is an integer.
> Now, it would be possible to emulate that with an appropriately-crafted
> PMC.
>
> So is it possible, after you write that PMC?
>
> Well... in theory, if you do this, you can write a gcc backend targeting
> parrot. It shouldn't even be /that/ difficult. (More difficult then
> porting gcc to a more traditional arch, less difficult then writing your
> own C, etc, compiler.)
>
> Unfortunately, since you've created that "memory" PMC, and stuffed much
> of your data in it, you no longer have assembler that resembles, even
> vaguely, that of the rest of the parrot world. Heck, most languages
> will end up putting most user-visible things in PMC registers, and
> you'll only ever use one. You'll never use string registers. You've
> got an implicit PMC argument to every function, and one that probably
> wants highlander (singleton) semantics as well.
>
> You can write C, C#, C++, Pascal, Objective-C, Java, etc, but it won't
> interoperlate with other Parrot code well (without stubs), if at all
> (the stubs may be quite difficult).
>
> Is it worthwhile anyway?
>
> Quite possibly.
>
> Is it easy?
>
> No.
>
> Will it do everything you want it to do?
>
> No.
>
> -=- James Mastros
Ouch! I believe I now understand the complication. (Please forgive my
ignorance if I say something really stupid in the next few paragraphs,
I'm very new to world of compilers/vm's and am probably attempting to do
something way over my head here...)
As I've been reading GCCINT (GCC Internals) especially in reference to
RTL and creation of patterns to match particular RTL isns, I've noticed
that RTL is expressed as a series of fairly low-level, fundamental,
machine-based operations (e.g. Add 2 Ints, Branch on Condition, Set
Condition Codes based on, etc).
I kept thinking to myself, well, even though many of RTL's ops that
need mapped are much lower-level than many PARROT ops, I *should* be
able to map them all satisfactorily. Unfortunately, I completely missed
the point of memory addressing. The problem, if I understand you
correctly, is that when RTL says, "Hey Add these 2 Ints for me..", I
have no way of knowing what those Ints represent. They could be a
Checkbook balance and a Deposit -or- they could be an address of the
Checkbook balance and the address of the Deposit. That address, in turn,
needs to be accessible by something like, "Load the Integer at this
address into the first (Integer) Register...." ---- Hmmmmm, that makes
me think....what if an instruction like:
"Store value X from Register Y at address pointed to by Register Z"
were implemented as storing Reg Y in an Expandable Array (or perhaps
Hash) where the value in Z represents the Index/Key into the Array. So,
in other words, an address related action is really a reference into and
Array (Hmmm.....that just sounds like a less efficient way to do it than
use a PMC pointing to a big hunk of memory a you suggested, No?)
OK, so the problem is that GCC's RTL representation is not rich enough
in semantics for the back-end to map what it needs to do PARROT in a
true PARROIISH fashion, correct? Could this *reasonably* (and I really
use this term LOOSELY) be solved by creating a richer RTL and changing
the Parse Tree->RTL stage to emit the richer semantic RTL rather than
the low-level RTL? Or, would it be more advisable to not use GCC at all
and simply focus on creation of direct-to-parrot compilers for various
languages?
Thanks for Your Input,
Gerry Butler
