🚀 go-pugleaf

real-address-in-sig@flur.bltigibbet (Rowland McDonnell) writes:

> David Kastrup <David.Kastrup@t-online.de> wrote:
> 
> > real-address-in-sig@flur.bltigibbet (Rowland McDonnell) writes:
> > 
> > > David Kastrup <David.Kastrup@t-online.de> wrote:
> > > 
> > > > And the
> > > > 8080 still was a rather clean design.  The Z80, in constrast, was
> > > > convenient but awful: the price you paid for some of its features was
> > > > prohibitively high.
> > > 
> > > Hmm...  Maybe, maybe - but was there anything missing from the Z80
> > > compared to the 8080?
> > 
> > No, it was upwards machine code compatible,
> 
> Righto - ta.  (memory told me that was the case).  So if the 8080's a
> rather clean design and the Z80 has everything the 8080 has, how can the
> Z80 be awful?

Because it is upwards machine code compatible.  That means that they
had to squeeze the additional commands of the Z80 into few remaining
opcodes, which necessitated compound opcodes.  Those were implemented
in microcode which still took considerable time to execute.  This lead
to longer execution times (and interrupt latencies).  For example,
things like rlc (ix+3) took up 23 clock cycles.  In contrast, ld e,3;
add hl,de; rlc (hl) took the same cycle count, was usually as
applicable, and introduced less interrupt latency.  In general, the
extended opcodes were quite longer, and you needed to know the
machine quite well in order to know when it would be better not to
use them.

Contrast this with the design of the 6809, for example, where the
indexing modes were sanely and tightly integrated into the processor
design.

> > but the assembly language
> > was more "natural"
> 
> Umm...  So if the Z80's got a more natural assembly language, doesn't
> that make it less awful than the 8080?

Could it be that you have difficulties comprehending the difference
between assembly language and machine language?  Restricting yourself
to the opcodes of 8080, you could use Z80 assembly language for
programming 8080 processors in a more readable manner.  The design of
assembly language readability bears no relation to the kludginess of
the processor design.

> > (as long as you did not use the upward compatible
> > TECO assembly language).
> 
> Uhuh.
> 
> > You could convert 8080 assembly language to
> > 8086 assembly language mechanically (register set and command set
> > matched, even though binaries didn't),
> 
> So I'd been told - but you seem to be a bit more authoritative than
> most...

Sole purpose of the LAHF and SAHF instructions (load/store AH register
to flags) is to facilitate reasonably fast replacements of the PUSH
PSW and POP PSW instructions from the 8080.  Your P4 processor still
has LAHF and SAHF.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de