🚀 go-pugleaf

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:
> > 
> > > 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.

Ah! - that makes sense.

>  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,

(just out of interest, is this all from memory, or (please tell me that
you do) do you look up the fine details?)

> 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.

Something which was pointed out to me a *long* time ago - I can recall
getting all excited over the powerful Z80 instructions until someone
mentioned the time it took to execute 'em.

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

Righto (I think I might even have a 6809 programming manual somewhere,
which doesn't help at all with the internals, does it?)

> > > 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?

I hope not.

>  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.

Well, yes; but up until that point, everything you'd said about the Z80
made it sound better than the 8080.

> > > (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. 

Coo!

> Your P4 processor still
> has LAHF and SAHF.

Not *my* P4 processor - it's 6502s, a Z80, 68000 series, and a couple of
PPCs in *this* house (plus whatever runs the calculators and the Psion 3
(some 8080-related low power thingy IIRC).  The washing machine is run
by a cam timer but I don't know what processor's built into this 'ere
monitor or the remote controls - is there no escape from the damned
things?).

Rowland.

-- 
Remove the animal for email address: rowland.mcdonnell@dog.physics.org
PGP pub key 0x62DCCA78                      Sorry - the spam got to me
                                                 http://www.mag-uk.org
UK biker?                    Join MAG and help keep bureaucracy at bay