Re: Retargetable assemblers and linkers? (Hannah Schroeter)
18 Dec 2000 00:31:55 -0500

          From comp.compilers

Related articles
Retargetable assemblers and linkers? (2000-11-11)
Re: Retargetable assemblers and linkers? (Joachim Durchholz) (2000-11-14)
Re: Retargetable assemblers and linkers? (2000-12-18)
| List of all articles for this month |

From: (Hannah Schroeter)
Newsgroups: comp.compilers
Date: 18 Dec 2000 00:31:55 -0500
Organization: Chaos
References: 00-11-089
Keywords: linker, assembler, comment
Posted-Date: 18 Dec 2000 00:31:55 EST


<> wrote:
>Are there such things? That is, I would like to feed my x86 compiler's
>code generator back end with sparc or mips code and have the proper
>object code generated. Even better if I then could call a retargetable
>linker... If there are no such beasts around, someone ought to make
>[Yes, there are programs that translate one machine language to another.
>DEC wrote a very complete one to translate VAX to Alpha, for example,
>and there have been a variety of JIT x86 to Sparc or 68K translators.
>It's a lot easier if source and target have the same byte order and
>otherwise similar data formats. -John]

I believe, in general, that problem should be impossible to solve.

See, the following code
char* c;
return c[0];
should probably translate to something like
move.b (a4), d0 ; assume that c is in a4
ext.w d0
ext.l d0 ; assuming that C defined char to be
; signed
rts ; modulo stack frame mangling
on 68000 (big endian) and to something like
ldrb r0, [r4,0] ; c is in r4
... ; perhaps sign extend
movs r14, r15 ; modulo stack frame mangling, this
; returns
on ARM (little endian, ldrb target-register, address = load register byte)

int* i;
return (signed int) ((char) ((i >> 24) & 255));
could translate to
move.b (a4), d0 ; assume i is in a4
ext.w d0
ext.l d0
on 68000 (big endian) on a compiler doing some algebraic transformations
(note that there's no difference to the code above!), while the code on
ARM must look different:
ldrb r0, [r4,3]
[sign extend]
movs r14, r15

An automatic translater from 68000 assembly/machine code to ARM
couldn't distinguish the two different intended meanings.

Kind regards,

[Of course you can translate code from one machine language to another,
doing byte reversals if need be. But it can certainly be slow. There
were some very clever DOS-on-SPARC and DOS-on-68K emulators that did
translations of chunks of code on the fly. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.