Leopold Toetsch wrote:My point with my previous response to Leopold's mail was that you could actually do CPU emulation at such a low parrot level that you wouldn't even have to do that (e.g. identify strings vs. array of int's) initially. You emulate at the register and opcode level. Performance would suffer (quite a bit), but you could get it working pretty easily. Then it's a matter of gradual optimization to recognize lower level structures that can map to more complex higher level parrot equivalents.
Tupshin Harper wrote:
I'm not a "GCC person", but I do have an interest in this working. INo :-) Most processors work stack-oriented. AFAIK does have the ia64
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?
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).
-Tupshin
