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