Re: Code translation
- From: s_dubrovich@xxxxxxxxx
- Date: 18 Jul 2005 17:23:23 -0700
Lee Hart wrote:
> from the "was there ever a CPM for..." thread:
> > I have to say, to simulate a Z80 on an 6502 would be a real
> > challange, and if it has been done, I wouldn't be surprised
> > it is extremely slow. 6502 is really limited in registers
> > and instructions compared to the Z80.
>
> This got me to thinking about an old problem again.
>
> When you automatically translate machine code from one CPU to another,
> the results are quite poor. Each instruction in the source code becomes
> multiple instructions of object code. The resulting program runs much
> slower, and takes much more memory.
>
> It's not that one CPU is "inferior" to the other; it doesn't matter much
> which way you go. A 6502 emulating a Z80 might run 10 times slower and
> need twice the memory. But a Z80 emulating a 6502 also runs 10 times
> slower and takes twices the memory.
>
> However, suppose the source program was in some high-level language,
> like C. Compile it for a Z80. Compile it for a 6502. Now the two
> machine-code programs are nearly the same size, and run at nearly the
> same speed. That's because the Z80 and 6502 are roughly equal performers
> (assuming same memory size and same bus cycle rates).
>
Seems to me the implementations of a HLL resolve down to abstract data
types, such as lists, stacks, fifo buffers [a form of list], trees; and
their operators. Those basic data abstractions can be implemented on
most cpu's to varying degrees of success. Hence, the HLL's are
portable.
> Of course we can bury the problem with vast overkill of memory and clock
> speeds; a 4 MHz 64k Z80 system can be emulated by a 400 MHz 64 megabyte
> Pentium PC.
>
> But shouldn't there be a more elegant, efficient solution? What Dr.
> Dobbs used to call "running light without overbyte"? It seems that what
> is needed is a decompiler; a program that disassembles a
> machine-language program for one CPU into some higher-level language,
> and then a recompiler that efficiently recompiles it for a *different*
> CPU.
>
Such as a reverse P-Code Decompiler? That would take a program an
decompile it into P-Code or some such, so you could recompile it for
another processor with a P-Code compiler. The abstract data types
should transfer. So the modern equivalent would be to decompile into a
Java Virtual Machine. Only, you are talking about: source cpu micro
code -> JVM -> target cpu micro code. So you need a decompile to Java,
and a JVM on the target cpu.
> One simple test to see whether this is possible is to ask ourselves, "Is
> it possible for a human to do this job?" I think the answer is "yes". On
> numerous occasions, I have read assembler code for one CPU to understand
> what it does, and then written equivalent code for another CPU that does
> the same thing. But there is *not* a 1:1 correspondence between the two;
> I may have to move things that were in registers into RAM, or reverse
> the byte order, or replaces sequences of instructions with a single
> instruction. It requires intelligence, but is an orderly process.
>
> But I have never a decompiler-recompiler program to do this on an
> automated basis. Has it been done? Has anyone even tried to do it?
> --
> If you would not be forgotten
> When your body's dead and rotten
> Then write of great deeds worth the reading
> Or do the great deeds worth repeating
> -- Ben Franklin, Poor Richard's Almanac
> --
> Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net
.
- Follow-Ups:
- Re: Code translation
- From: Lee Hart
- Re: Code translation
- References:
- Code translation
- From: Lee Hart
- Code translation
- Prev by Date: Re: Code translation
- Next by Date: Re: 1972 Garrett 2000 RPN Calculator
- Previous by thread: Re: Code translation
- Next by thread: Re: Code translation
- Index(es):
Relevant Pages
|
