4 Apr
2006
4 Apr
'06
12:26 p.m.
On Tuesday 04 April 2006 09:08 am, Don Y wrote:
Z80 is a different beast from the 808[05]. You write code differently for
it because it has a much richer instruction set.
But I never used most of that stuff. Never got around to doing anything with
the index registers, the alternate set, or a lot of those "specials" that
were added. I kinda liked relative jumps, though, since it made it way
easier to do relocatable code and plus they were a byte smaller. :-)
Just so.
Yep!
Sometimes I like the absolutely minimalist approach to things, too. One of
these days I'm gonna dig that code out, burn it, and see how small a z80
box I can build that'll still prove useful for all sorts of things. I sure
have enough of those parts on hand here...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Roy J. Tellason wrote:
Yes. And I often wished that they'd had one that would work with BC, as
well... :-)
On Monday 03 April 2006 12:57 am, Don Y wrote:
As was PCHL. But, XCHG was lots of bang for the buck (4 clocks?) I think the real reason (?) goes to a difference
in cultures between
register rich and register poor machines IN THAT TIMEFRAME.
I think you're probably right...
E.g., if you are writing code for a 68xx, you
have little choice
but to do everything in memory addressing. Whereas if you are
using 8080/8085/Z80 et al., you just get used to *keeping* things
in registers (I can recall spending lots of time evaluating
which arguments I would put in which registers so I could
*keep* them there -- or somewhere else in the register set -- for
the duration of the algorithm... XCHG being a favorite tool
in those cases!)
Yeah. Though XTHL was another one... because it moved a lot of data in a little time. By
contrast,
XTHL (ex sp,(hl) for z80 folks) moved the same amount of data
but, since it went to TOS, there were a lot more clocks involved
(19 or 20, IIRC).
Yup.
Moving to something like a 99000 can be terribly
distressing
for the register rich crowd to become accustomed to! ;)
I found, though, when I was doing some z80 stuff a while back that most
of the time I'd use one pair for an address pointer and maybe one other
besides the accumulator and that was it, over 90% of the time. But, if you are doing things like adding an 8 digit
BCD number to another 8
digit BCD number, you quickly discover that you need a lot of registers (two
pointers for the two arguments -- assuming the destination is one
of these as well, a "digit counter", the accumulator and, of course, the
carry).
I suppose. I guess it all depends on what you want to do...
Oh, and the
little monitor program that I was playing with didn't push a
parameter on to the stack, it put it inline, right after the call to
some subroutine -- the called code would pick it up and use it and adjust
the stack pointer to just past it for the return. :-)
Yes, a favorite trick for "printing" strings, etc.
CALL OUTPUT
DB 'Hello, World!'
<insert next instruction here> I have to dig
out that code, anyhow, there were a few little tricks in
there that I think I want to use again. Like funneling everything
through a dispatch table, so that un-programmed EPROM showing up as
"FFFF" in some entries would be handled automatically ("CRASH!" :-),
ferinstance.
Or, using INR M to 'test' flags.