This week's summary
Tupshin Harper
> Targeting Parrot from GCC
> Discussion in the thread entitled 'WxWindows Support / Interfacing
> Libraries' centred on writing a Parrot backend to GCC. (No, I have no
> idea what that has to do with the thread subject.) Tupshin Harper, Leo
> Tötsch and Benjamin Goldberg discussed possibilities and potential
> pit/pratfalls. At one point, Tupshin suggested emulating a 'more
> traditional stack-oriented processor' and I don't think he was joking...
>
>
Indeed, I wasn't, but I wish somebody would at least have the decency to
tell me how insane this is. ;-)
-Tupshin
Rhys Weatherley
> At one point, Tupshin suggested emulating a 'more
> > traditional stack-oriented processor' and I don't think he was
> > joking...
>
> Indeed, I wasn't, but I wish somebody would at least have the decency to
> tell me how insane this is. ;-)
Have a look at the Portable.NET FAQ, which describes some of the difficulties
in targetting stack machines with gcc.
http://www.southern-storm.com.au/pnet_faq.html#q4_7
Cheers,
Rhys.
Tupshin Harper
> Have a look at the Portable.NET FAQ, which describes some of the
> difficulties
>
>in targetting stack machines with gcc.
>
>http://www.southern-storm.com.au/pnet_faq.html#q4_7
>
>Cheers,
>
>Rhys.
>
>
>
Yeah...I've read that before. But it doesn't mention the possibility of
emulating a more traditional CPU that could be targeted by gcc.
-Tupshin
Dan Sugalski
Oh, sorry.
You're insane. :)
Traditional processors aren't stack-oriented, not even ones that are
more register-starved than the x86 family. (I'm thinking of the 6502
with it's 1.75 registers here)
The base architecture's fixed, and I'm not inclined to change it at
this point. GCC could handle it if someone wanted to work it out--it
can already deal with multiple register classes, since most machines
these days have at least two (general purpose and float) and the ones
with vector processors arguably have three types. It'd probably have
to do less work for parrot than for other systems, as we have more
registers, and register starvation's one of the more annoying things
a compiler has to deal with.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Paolo Molaro
> >> pit/pratfalls. At one point, Tupshin suggested emulating a 'more
> >> traditional stack-oriented processor' and I don't think he was
> >> joking...
> >>
> >Indeed, I wasn't, but I wish somebody would at least have the
> >decency to tell me how insane this is. ;-)
>
> Oh, sorry.
>
> You're insane. :)
>
> Traditional processors aren't stack-oriented, not even ones that are
> more register-starved than the x86 family. (I'm thinking of the 6502
> with it's 1.75 registers here)
The wording "stack-oriented processor" is a little misleading, since it
usually means the processor has a stack-oriented instruction set,
instead of a register one. The original context, instead, implies it
refers to GCC's assumptions about the existence of the runtime stack
(as the contiguous area of memory where call frames are stored).
There is already a (limited) gcc backend that targets the CLR that
sets up an area of memory for that use, but, as you can guess, it's not
vey nice.
> The base architecture's fixed, and I'm not inclined to change it at
> this point. GCC could handle it if someone wanted to work it out--it
> can already deal with multiple register classes, since most machines
> these days have at least two (general purpose and float) and the ones
> with vector processors arguably have three types. It'd probably have
> to do less work for parrot than for other systems, as we have more
> registers, and register starvation's one of the more annoying things
> a compiler has to deal with.
I think a gcc port would require parrot to provide at least a stack
memory area and a register (sp) that points to it. There may be other
issues with the parrot instruction set, but since you have already
hundreds (or thousands?) of opcodes, I guess it wouldn't be an issue to
add a few more if needed:-)
lupus
--
-----------------------------------------------------------------
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
Tupshin Harper
> At 4:23 PM -0700 7/15/03, Tupshin Harper wrote:
>
>> Piers Cawley wrote:
>>
>>> Targeting Parrot from GCC
>>> Discussion in the thread entitled 'WxWindows Support / Interfacing
>>> Libraries' centred on writing a Parrot backend to GCC. (No, I
>>> have no
>>> idea what that has to do with the thread subject.) Tupshin
>>> Harper, Leo
>>> Tötsch and Benjamin Goldberg discussed possibilities and potential
>>> pit/pratfalls. At one point, Tupshin suggested emulating a 'more
>>> traditional stack-oriented processor' and I don't think he was
>>> joking...
>>>
>> Indeed, I wasn't, but I wish somebody would at least have the decency
>> to tell me how insane this is. ;-)
>
>
> Oh, sorry.
>
> You're insane. :)
Thank you...I feel much better now.
>
>
> Traditional processors aren't stack-oriented, not even ones that are
> more register-starved than the x86 family. (I'm thinking of the 6502
> with it's 1.75 registers here)
Yes, I know. The issue is that GCC is practically hard-wired to use
C-style stack frames.
>
>
> The base architecture's fixed, and I'm not inclined to change it at
> this point.
Absolutely...I was never suggesting implementing anything at the base
architecture level. I believe that everything necessary could be
implemented in some additional PMCs, and some minor extensions to the
pasm format.
-Manically yours
-Tupshin
Tupshin Harper
>>Traditional processors aren't stack-oriented, not even ones that are
>>more register-starved than the x86 family. (I'm thinking of the 6502
>>with it's 1.75 registers here)
>>
>>
>
>The wording "stack-oriented processor" is a little misleading, since it
>usually means the processor has a stack-oriented instruction set,
>instead of a register one. The original context, instead, implies it
>refers to GCC's assumptions about the existence of the runtime stack
>(as the contiguous area of memory where call frames are stored).
>
Exactly.
> I think a gcc port would require parrot to provide at least a stack
>
>memory area and a register (sp) that points to it. There may be other
>issues with the parrot instruction set, but since you have already
>hundreds (or thousands?) of opcodes, I guess it wouldn't be an issue to
>add a few more if needed:-).
>
This exactly mirrors my thinking on the issue.
-Tupshin
Dan Sugalski
>Dan Sugalski wrote:
>>Traditional processors aren't stack-oriented, not even ones that
>>are more register-starved than the x86 family. (I'm thinking of the
>>6502 with it's 1.75 registers here)
>
>Yes, I know. The issue is that GCC is practically hard-wired to use
>C-style stack frames.
Yep, and for it to interoperate with Parrot, it'd need to lose that.
There's no way around it if we want to have it generate code that
conforms to the calling conventions, since the presence (heck, heavy
use) of continuations pretty much demands heap-allocated frames
rather than stack frames.