Z80 to x86 asm translator?

Question

8086 is source code compatible with 8080. Zilog Z80 extended Intel 8080 with:

• An enhanced instruction set including bit manipulation, block move, block I/O, and byte search instructions
• New IX and IY index registers with instructions for direct base+offset addressing
• A better interrupt system...[1]

Is it possible to translate Z80 asm into 8086, even with different register layout? There was a translator but it left some opcode untranslated and needed human intervention.

PS: What about 8085's extention to 8080? Can these features be adapted for Z80 or 8086?

Illustration of four syntaxes, using samples of equivalent, or (for 8086) very similar, load and store instructions.

Intel 8008 Datapoint 2200	Intel 8080 Intel 8085	Zilog Z80	Intel 8086 Intel 8088
before ca. 1973	ca. 1974	1976	1978
LBC	MOV B,C	LD B,C	MOV BL,CL
—	LDAX B	LD A,(BC)	MOV AL,[BX]
LAM	MOV A,M	LD A,(HL)	MOV AL,[BP]
LBM	MOV B,M	LD B,(HL)	MOV BL,[BP]
—	STAX D	LD (DE),A	MOV [DX],AL[x]
LMA	MOV M,A	LD (HL),A	MOV [BP],AL
LMC	MOV M,C	LD (HL),C	MOV [BP],CL
LDI 56	MVI D,56	LD D,56	MOV DL,56
LMI 56	MVI M,56	LD (HL),56	MOV byte ptr [BP],56
—	LDA 1234	LD A,(1234)	MOV AL,[1234]
—	STA 1234	LD (1234),A	MOV [1234],AL
—	—	LD B,(IX+56)	MOV BL,[SI+56]
—	—	LD (IX+56),C	MOV [SI+56],CL
—	—	LD (IY+56),78	MOV byte ptr [DI+56],78
—	LXI B,1234	LD BC,1234	MOV BX,1234
—	LXI H,1234	LD HL,1234	MOV BP,1234
—	SHLD 1234	LD (1234),HL	MOV [1234],BP
—	LHLD 1234	LD HL,(1234)	MOV BP,[1234]
—	—	LD BC,(1234)	MOV BX,[1234]
—	—	LD IX,(1234)	MOV SI,[1234]

Answer 1

I'm going to say "No" simply because the 8086 doesn't support the alternate registers of the Z80. That was a fairly important concept that you can not directly mimic on the 8086.

Mind, if you're willing to dedicate memory and whatnot to support it, then, "sure". Replace the Z80 functionality with a macro, say. But now you're stretching it. Your instruction count was going to change.

Also 8086 MOVSB is not the same as the Z80 LDIR, it works on different registers.

There may well be other differences.

The idea was that you could translate 8080 to 8086, one instruction for one instruction. But the Z80 was not an Intel chip, it was a Zilog chip. As much as Intel may have wanted to perhaps support it, they may have chosen not too.

So, a 1:1 Z80 ⟶ 8086 translation could not be done perfectly. You could get quite a ways with a simple macro assembler, but there would absolutely be differences that would best be hand-checked in the end.

Answer 2

Sure, a lot can be done. Source code translation always offers the possibility to replace one instruction by a sequence - like Intel already did for a few. This would as well solve the issue of incompatible hardware, like simply exchanging all registers with a copy in memory when the alternate register set is selected.

Just, who should do this?

Intel had only interest to support their customers. Taking on all the support pitfalls for a rare chance to win over customers that have already left Intel? With a CPU that, despite all improvements, still cannot compete with the Z80 in the important area of interrupt handling? Interrupt handling was the main reason for professional customers to switch to Zilog. Not funny instructions.

Zilog had even less motivation to support porting Z80 code to x86 as that would mean losing customers.

Lastly, there would be software companies, but their need was also rather limited. The ones writing machine-independent software did not use Z80 extensions, as they preferred to have a single binary for all of the CP/M world. Producers of machine-dependent software on the other hand were much more about performance; any automatic translation would have helped only at the curiosity level.

For the 8085, Intel simply resolved that issue by not making any of the new instructions officially available. The only official new ones were RIM/SIM and these are part of interrupt management, something that had to be rewritten anyway when porting to x86.

Bottom line

While it would be possible, there was no real need to do so.

Answer 3

First, note that although Intel claimed 8080-to-8086 asm source compatibility, their CONV86 was slow, cranky, and produced bloated code that often had outright errors. Converting from Z80 asm obviously inherits all the difficulties of 8080-to-8086 translation and adds more, which is why SCP's (later, Microsoft's) TRANS86 just attacked a tractable, human-assisted subset of the problem.

8080-to-8086 "translation" was done much better by the 1982 Digital Research XLT86, but its behavior indicates the actual path necessary. DR XLT86 was based on optimizing compiler techniques. It was willing to fold, spindle, and mutilate 8080 assembly as if it were any other language being compiled for the 8086.

Approached that way, it certainly would be possible to use optimizing compiler techniques to take Z80 assembly and output 8086 assembly (or object code) . . . but it would obviously be possible to do the same thing to take Z80 assembly and output ARM assembly (or object code). With modern compiler techniques, it's not even apparent that Z80-to-8086 would be an easier task than Z80-to-ARM.