Tupshin Harper wrote:
I'm not a "GCC person", but I do have an interest in this working. I did some exploratory work (mostly getting familiar with the GCC backend mechanism and with PASM), and quickly ran into what appeared to be fundamental roadblocks regarding gcc's predilection for generating stack-oriented assembly. Do you have some insights into what the most viable path for GCC--->pasm could be?
No :-) Most processors work stack-oriented. AFAIK does have the ia64 cpu some deviations like register windows. But parrot - and the more with CPS subroutines - is really different. And parrot has a different ABI too.
Translating IReg and Nreg operations wouldn't be too hard, but what about strings (and functions) and objects. I think, that is impossible.
I'm confused...it sounds like you are talking about translating pbc->regular CPU, and I'm thinking the opposite.
Here's a wacky idea. What about emulating a more traditional stack-oriented processor in parrot? (What...surely you jest). Seriously, though, it might actually be a really thin emulation layer. You add some PMC's to handle C-style stacks and any other CPU oddities that would be expected of a back-end by a compiler. How complicated could it be? Obviously performance would suffer, but it seems workable.
Targeting native C is not a primary goal, just some "nice to have". IIRC do the mono people have a C parser too and there are some thoughts to translate C/C# to parrot, so I can imagine, that there might be some more in the future.
-Tupshin
leo
-Tupshin
