Leopold Toetsch wrote:
>
> 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.
Since the discussion is (gcc-produced-)assembly to pasm, we're
fortunate... there aren't any "objects" to translate from asm to pasm :)
For strings, the real challenge is identifying when the assembler is
manipulating something which should be thought of as a string, or when
it is manipulating something which should be thought of as an array of
character-sized integers; then we use either Sreg operations, or Preg
operations (operating on some Array (sub-)type).
> 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.
Translating from pasm to C would be very similar to our jit, except that
instead of outputing assembler, we would output C source code, most of
which could probably be generated from the data in our *.ops files.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
