21

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]
Improve this question
5
  • 1
    If you try to make LD A,(BC) translate to MOV AL,[BX] you've got the problem that in the Z80 case the address would have been loaded into B and C, and in the 8086/8 case the address would have therefore been loaded into BL and CL, not BX Commented Apr 14, 2021 at 12:11
  • 1
    @user7761803 Due that reason the registers aren't assigned like you assumed. It's basically like this: A-> AL; B/C -> CX; D/E -> DX; H/L -> BX; SP -> SP. Now all works as expected, doesn't it? Commented Apr 14, 2021 at 22:22
  • Here's an example of somone translating GW BASIC the other way 8086->Z80 tia.mat.br/posts/2020/06/21/converting-gwbasic-to-z80.html . However, this is mostly 8080 code, so maybe doesn't count. Commented Apr 15, 2021 at 8:15
  • I'd say that '8086 source code compatible to 8080' is actually a vast marketoid exaggeration. It is, in fact, not, examples are given below in the answers and above in the comments. Of course, one can translate almost each assembler to another, then even optimize it (given rather intellectual translator, either JIT or source-code-based, or just manually), but does that makes them all 'source code compatible'? Commented Apr 15, 2021 at 19:44
  • @lvd If Intel had a product that could automatically translate the source code with the simple 1-1 mapping described by Raffzahn without any further human interaction, and the resulting binary worked as the original, then it is true and not an exaggeration. Commented Dec 21, 2021 at 5:48

3 Answers 3

Reset to default
24

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.

Improve this answer
2
  • 5
    "The idea was that you could translate 8080 to 8086, one instruction for one instruction" - not quite; there were a few 8080 instructions that translated into multiple 8086 instructions; for example, PUSH PSW -> LAHF; PUSH AX, and RZ -> JNZ skip; RET; skip: Commented Apr 14, 2021 at 13:28
  • 2
    I wonder how often the LAHF/PUSH AX represented the behavior that a program would actually need, and how often PUSHF/PUSH AX would be better despite the extra stack space. An interrupt handler that trashes AH would be highly disruptive, for example, unless none of the main line code used AH at all--not even as part of an LAHF/PUSH AX sequence. Commented Apr 14, 2021 at 22:41
14

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.

Improve this answer
7
  • I wonder if it's feasible that z80 be inserted into and considered a part of 8008-8080-8086 evolving tree especially for a 3rd party manufacturer such as the USSR. Commented Apr 14, 2021 at 5:40
  • @Schezuk Would it matter? The switch happened anyway, no matter if one did put an emphasis on the 8080, like the USSR did, or used the Z80 instead, like the GDR did. Both ended up going for 8086 later on. GDR even somewhat faster IIRC. Commented Apr 14, 2021 at 5:42
  • 1
    8086 in the USSR? I can't think of any such computer. Commented Apr 14, 2021 at 10:20
  • @OmarL see wiki K1810VM86 Commented Apr 14, 2021 at 15:05
  • 3
    @Schezuk Isn't that more like another question? In general, look at the Interrupt response time. The great advantage of the Z80 over the 8080 was it's direct(er) interrupt handling and second register set, saving many cycles when used for this. Speeding response time up quite a lot. While interrupt handling was eased on the 86 by having more vectors, it was slower as well due long vectors and register saving. So Z80 could, at similar clockspeeds, still run circles around an 8086. Commented Apr 15, 2021 at 10:48
4

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.