20 Apr
2006
20 Apr
'06
5:29 a.m.
But the Z80
and the 8085 are both based on the 8080 architecture
and instruction set - so much so that they will both run the vast
majority of 8080 code.
But that's a fallacy. You have to tweek the code in almost
all cases (especially if you are designing embedded systems
and not "desktop applications"). So, a smarter approach is
to handle things at the *source* level instead of the *object*. Is anyone
really suggesting that it's an
"accident" that the Z80 happens to run 8080 code ... or did
Zilog begin with the 8080 instruction set definition (hence my point
that they (Zilog) did not make the decision on the bit arrangements
of the opcoodes).
But a Z80 *won't* run 808[05] code. Nor will a 64180 run
Z80 code. (and "Rabbits" don't run anything! :> ) Zilog made
a very conscious decision to make a "different 808x". Everything
from the pinouts, peripherals available, bus timing, etc.
(where did RST 5.5 go? etc.). Nor did they adhere to
Intel's mnemonics (copywritten?) -- though converting from
one to the other is almost trivial with even the macroassemblers
available back then. Tek used a still different set of
opcodes in their tools, etc. And, there is no reason why xx ddd sss is any *better*
than
xs dsd sdx or sd xxd ssd for an instruction encoding. *We*
used (split) octal because our MTOS supported hot patching
and it was convenient to "hand assemble" code patches on the
fly to fix bugs, etc. (gdb wasn't around for an 8080 in ~1976)
Doesn't this suggest that xxdddsss actually was *better* - since
you took advantage of the alignment with octal notation to make it
easier to hand-assemble... And, tracking 16 bit load/stores (LXI's,
PUSH's, etc.)
requires memorizing an encoding for *4* possible arguments.
Yes - these are included in the "Non-octal" catagory above.
And who can recall the clever encoding of all of the
conditionals?
Tough if you think in hex (the conditon field would be split across two
nibbles ... but if you think in Octal, it's not so tough ... all conditions
are represented in the second triplet (from the right):
000 = 0 = NZ
001 = 1 = Z
010 = 2 = NC
011 = 3 = C
100 = 4 = PO
101 = 5 = PE
110 = 6 = P
111 = 7 = M
All transfer instruction are encoded: 11 ccc xxx
Where xxis:
000 = Rcondition
010 = Jcondition
100 = Ccondition
As noted
earlier, I happen to be from the "hex" camp ... but I don't
think it's fair to dismiss the octal guys as "nuts" ... the use of octal
on the 8080 did have some benefit, and there were a lot of people
who went that route - to ignore or discount this does not present an
accurate depiction of the time period.
When I worked on 8085's, we let the MDS-800 handle the assemblies.
Burn a set of EPROMs (2 hours!), plug into the target and hope
you've stubbed enough places in the code so you could figure out
where it was based on examining odd display patterns, etc.
Stare at listings, burn another set of EPROMs after lunch.
Two turns of the crank in an 8 hour shift. Did the choice of
opcode assignments increase productivity?? When I was doing Z80-based designs (in the "split
octal" world),
a helluva lot of energy was expended to support the "octal"
encoding -- rewriting the Zilog assembler to generate listings
in octal (INCLUDING displaying addresses in split octal!),
building run-time "monitors" to examine and patch code images
during execution, writing the associated software to do so, etc.
This would be because you didn't work in Octal (split or otherwise).
The same could be said for any encoding scheme - If some of your
users had demanded to use base 13 this too would have presented a
challange to you - but at least the "ultimate answer" would work out
correctly: (6x9=42 in base 13 :-)
I'm convinced the fact that you could get a
ten-key
keypad and an inexpensive LCD to display 6 digit SPLIT octal
values had more of an impact on the octal decision than
anything about the opcode encoding -- despite the fact that
it made USING the tools more difficult (since you can only
display a 16 bit value -- *address* -- in 6 digits, you have
to multiplex the display to let the user see the *data* at
that address :< ).
That was certainly part of it - as was the fact that 7447's could
display Octal quite nicely, but didn't work so well with Hex.
But I would also say that a higher percentage of single-board
8080 machines used Octal - because it does make sense
with the instruction set.
I recall getting an EM-180 and quickly distancing
myself
from the octal vs. hex debate... I'll use *symbols* instead
of dicking around with bit groupings.
Why even bother with that ... why not just use mouse clicks
and "drag and drop".
In the days of wirewrap systems, homebrew front panels
and pencil and pad assemblers, bit groupings mattered.
One question though --- since you use symbols and don't
"dick around" with bit groupings ... why is the use of Hex
over Octal so important to you? ... wouldn't one be just as
good as the other to the high level view (like some detail
burried way down in the mouse driver that you don't need
to care about when you click).
Now why some
people chose octal for other processors, which
didn't have an architectural slant toward 8 is more of a mystery
to me....
I think the fact that 0..7 fits in a decimal representation
says a lot about the "why". :-( Amazing to consider how
much "resources" got wasted on silly (in hindsight) decisions.
Sort of like PC (and other) BIOS decisions placing silly
restrictions on the size of a disk or where the boot code
can be located, etc.