[comp.arch] Zilog's mnemonics; a boon to programmers

djh@neuromancer.metaphor.com (Dallas J. Hodgson) (11/13/90)

In article <1990Nov9.164838.26423@amd.com> ching@brahms.amd.com (Mike Ching) writes:
>In article <9333@b11.ingr.com> lhughes@b11.ingr.com (Lawrence Hughes) writes:
>...
>>
>>The Z80 WAS upward compatible with the 8080, at both architecture and binary
>>opcode level - curiously enough, though, the bright boys at Zilog invented
>>a better (read "different and incompatible") symbolic assembly langauge
>>which made it much more difficult to take advantage of the Z80's extended
>>instructions: you either stuck with Intel mnemonics (and the 8080 subset) or
>>worked with Zilog's "preverted" ones (e.g. almost half the actual binary 
>>opcodes mapped onto the single symbolic opcode "LD"). Zilog's symbolic
>>language was SUCH a turkey, that several extended Intel symbolic assembly 
>>languages were developed (and widely used) leading to a regular tower of Babel.
>>Clever, Zilog.

Ahem, excuse me, but Zilog's mnemonics were readable and orthogonal in a way
that Intel's never were, and were by far the more popular standard for Z-80
programming. Intel was never quite sure how to recast the Z-80 extended ops
into their particular mold; often their syntax was just borrowed "as is"
from the TDL Zilog format. Unless you had a vested interest in the 8080 for
some reason, Zilog mnemonics were simply the preferred way to go. It's
interesting to note that Zilog was founded by ex-Intelites.

On the binary opcode level, the Z80's instructions were mondo hack attempts
to extend the language while maintaining almost complete backward
compatibility with the 8080. Simple conversion programs have always been
available to translate between different formats, so I don't see any reason
to get religious over this issue. Frankly, this is the first time I've
ever heard ANYONE get religious over Intel's (!@#?!) assembler syntax.

Now Motorola, there's a company that really did things right...

LDIR! CPIR! EXX! Reasons to Live!
+----------------------------------------------------------------------------+
| Dallas J. Hodgson               |     "This here's the wattle,             |
| Metaphor Computer Systems       |      It's the emblem of our land.        |
| Mountain View, Ca.              |      You can put it in a bottle,         |
| USENET : djh@metaphor.com       |      You can hold it in your hand."      |
+============================================================================+
| "The views I express are my own, and not necessarily those of my employer" |
+----------------------------------------------------------------------------+

richard@aiai.ed.ac.uk (Richard Tobin) (11/14/90)

In article <1768@metaphor.Metaphor.COM> djh@neuromancer.metaphor.com (Dallas J. Hodgson) writes:
>Ahem, excuse me, but Zilog's mnemonics were readable and orthogonal in a way
>that Intel's never were

Quite true.  The problem was that the orthogonality of the mnemonics
led one to write instructions that didn't in fact exist.

-- Richard

-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin

gene@cooper.cooper.EDU (Gene (the Spook) ) (11/15/90)

in article <1768@metaphor.Metaphor.COM|, djh@neuromancer.metaphor.com (Dallas J. Hodgson) says:
| 
| In article <1990Nov9.164838.26423@amd.com| ching@brahms.amd.com (Mike Ching) writes:
||In article <9333@b11.ingr.com| lhughes@b11.ingr.com (Lawrence Hughes) writes:
||...
|||
|||The Z80 WAS upward compatible with the 8080, at both architecture and binary
|||opcode level - curiously enough, though, the bright boys at Zilog invented
|||a better (read "different and incompatible") symbolic assembly langauge
|||which made it much more difficult to take advantage of the Z80's extended
|||instructions: you either stuck with Intel mnemonics (and the 8080 subset) or
|||worked with Zilog's "preverted" ones (e.g. almost half the actual binary 
|||opcodes mapped onto the single symbolic opcode "LD"). Zilog's symbolic
|||language was SUCH a turkey, that several extended Intel symbolic assembly 
|||languages were developed (and widely used) leading to a regular tower of Babel.
|||Clever, Zilog.
| 
| Ahem, excuse me, but Zilog's mnemonics were readable and orthogonal in a way
| that Intel's never were, and were by far the more popular standard for Z-80
| programming. Intel was never quite sure how to recast the Z-80 extended ops
| into their particular mold; often their syntax was just borrowed "as is"
| from the TDL Zilog format. Unless you had a vested interest in the 8080 for
| some reason, Zilog mnemonics were simply the preferred way to go. It's
| interesting to note that Zilog was founded by ex-Intelites.
| 
| On the binary opcode level, the Z80's instructions were mondo hack attempts
| to extend the language while maintaining almost complete backward
| compatibility with the 8080. Simple conversion programs have always been
| available to translate between different formats, so I don't see any reason
| to get religious over this issue. Frankly, this is the first time I've
| ever heard ANYONE get religious over Intel's (!@#?!) assembler syntax.
| 
| Now Motorola, there's a company that really did things right...
| 
| LDIR! CPIR! EXX! Reasons to Live!

Pardon my French, but...

	A-fuckin-men!

							Spookfully yours,
							Gene

graeme@labtam.labtam.oz (Graeme Gill) (11/16/90)

In article <3747@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes:
> In article <1768@metaphor.Metaphor.COM> djh@neuromancer.metaphor.com (Dallas J. Hodgson) writes:
> >Ahem, excuse me, but Zilog's mnemonics were readable and orthogonal in a way
> >that Intel's never were
> 
> Quite true.  The problem was that the orthogonality of the mnemonics
> led one to write instructions that didn't in fact exist.
> 

	and this took a little while to learn, but was made easier thanks to
some really useful charts showing the legal combinations of mnemonics
and registers, together with the op codes in the Zilog data book. Made had
assembly pretty easy too.
	One thing that drove me nuts about the 8086 was the lack of any
comparable aid in charting out its non-orthagonalities, and legal addressing/
register combinations.

	Graeme Gill

floyd@hayes.ims.alaska.edu (Floyd Davidson) (11/16/90)

In article <5584@labtam.labtam.oz> graeme@labtam.labtam.oz (Graeme Gill) writes:
>In article <3747@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes:
>> In article <1768@metaphor.Metaphor.COM> djh@neuromancer.metaphor.com (Dallas J. Hodgson) writes:
>> >Ahem, excuse me, but Zilog's mnemonics were readable and orthogonal in a way
>> >that Intel's never were
>> 
>> Quite true.  The problem was that the orthogonality of the mnemonics
>> led one to write instructions that didn't in fact exist.
>> 
>
>	and this took a little while to learn, but was made easier thanks to
>some really useful charts showing the legal combinations of mnemonics
>and registers, together with the op codes in the Zilog data book. Made had
>assembly pretty easy too.

It is also true that some of those instructions that don't exist (in
the books, anyway) do some strange things, some of which were very
useful.  It has been too long for me to remember exactly what they
are, but I think 8 bit manipulation of the index registers were the
useful ones.

( And who actually found Intel mnemonics better than Zilog?? Yucckkkkk)

Floyd




-- 
Floyd L. Davidson   floyd@hayes.ims.alaska.edu    floydd@chinet.chi.il.us
Salcha, AK 99714    connected by paycheck to Alascom, Inc.
When *I* speak for them, one of us will be *out* of business in a hurry.

gene@cooper.cooper.EDU (Gene (the Spook) ) (11/17/90)

in article <1990Nov16.050844.12539@hayes.ims.alaska.edu>, floyd@hayes.ims.alaska.edu (Floyd Davidson) says:
> It is also true that some of those instructions that don't exist (in
> the books, anyway) do some strange things, some of which were very
> useful.  It has been too long for me to remember exactly what they
> are, but I think 8 bit manipulation of the index registers were the
> useful ones.

Yup.  The ALE editor/assembler for old TRS-80s even supported those
instructions!  You could do things such as setting the high- or low-
byte of the IX and IY registers by specifying the instruction as
	<op>	{HX|LX|HY|LY}
when HX is the high byte of the IX register, LX is the low byte of the
IX register, HY is the high byte of the IY register, and LY is the low
byte of the IY register.

Also, you could easily get 2x+1 from a register containing value x by
using the SLS (shift left and set) pseudo-instruction.  This grew from
the fact that there was a shift right arithmetic, shift left arithmetic,
and shift right logical, but no shift left logical.  The Z80 would
shift the quantity x left by one (2x), and set the LSB (+1).  Nifty
for doing "trick" multiplies.

According to every source for the Z80 (as far as I know), all these
pseudo-instructions worked just fine, but were neither tested-for
nor guaranteed.

Also, if I'm not mistaken, the Z[12]80 support similar operations.

Play with them and have fun!

(BTW, try to get hold of an old 6502 and use the HCF (halt and catch
fire) instruction.  Loads of laughs.  Impress your friends.)

						Spookfully yours,
						Gene

adamd@rhi.hi.is (Adam David) (11/18/90)

In <3073@cooper.cooper.EDU> gene@cooper.cooper.EDU (Gene (the Spook) ) writes:

>According to every source for the Z80 (as far as I know), all these
>pseudo-instructions worked just fine, but were neither tested-for
>nor guaranteed.

Some of them have it, and some of them don't. It depends on the manufacturer
and which revision of the silicon.

>Also, if I'm not mistaken, the Z[12]80 support similar operations.

Well, yes and no. Both chips have an undefined opcode trap, which calls an
exception routine if the instruction is not defined.

According to the Z180 manual, no instructions are defined to access IXH, IXL,
IYH, IYL or "shift left and set" operations. These would then be diverted via
exception handler but the only practical reason for emulating them is to test
software for another system which does support them as opcodes.

The Z280 supports all the opcodes which access individual bytes of IX and IY.
There are also many new instructions and some new addressing modes, for instance
SP and PC relative modes, base+index addressing. JP and CALL relative, index
with 16-bit displacement, etc. etc. etc. There is good multiprocessor support in
hardware. The "shift left and set" instructions no longer exist though, and
have been replaced by "test and set". This change can be used to determine which
CPU is present. The undocumented Z80 opcode for IN F,(C) is also official on the
Z280 but is renamed and might therefore have changed slightly.

>Play with them and have fun!

Yes, there may well be several other useful instructions hiding in the Z80
(and probably different ones depending on whose Z80 and which one).

>(BTW, try to get hold of an old 6502 and use the HCF (halt and catch
>fire) instruction.  Loads of laughs.  Impress your friends.)

I guess the Z80 is more robust than this (?).

BTW, does anyone know what happened to the NEC V25 chip? That was the 8086 with
a Z80 compatibility mode.


Adam David.       adamd@rhi.hi.is