#Tell me about OS-9
9 messages in this thread
Sometimes DBcc is real handy. I remember using it for a high-speed
IEEE-488 transfer and it was _much_ faster than any other method (besides
DMA, which I didn't have at the time).
Well, I can certainly forget about any career in technical writing, can't
I? So far I'm batting about a 1.000 in misrepresenting my own views. You're
right, of course, disliking DBcc is exactly what I said. What I _meant_ is
that DBcc's terminating on a result of -1 is my pet peeve, not very
intuitive to initialize a loop with a count of 7 for 8 iterations. Then,
of course, you have to decrement the count before using it if it's
generated at run-time or compile time. Don't know why they did that.
I agree. DBcc is not intuitive at all on the loop ending count, and I
remember having to read the docs several times to realize they really meant
what they said <grin>.
The ending loop count on a DBcc doesn't really bother me much. What IS a
pain is that it only uses the low 16 bits of the data register. I HATE
having to code double loops to copy a Meg of data.
BTW, you'll pick up a heck of a lot more speed by unfolding your loops than
you do with just the DBcc.
And you can pick up a LOT more speed by using MOVEM.L to copy data. The
Exec CopyMem() and CopymemQuick() are about as fast as it goes in fact…
On the 68000 the MOVEM.L would give you alot more speed. You'll have to
excuse me, I spend most of my time programming 68020's and tend to forget
that the 68000 doesn't have an instruction cache, which drastically alters
the instruction timing.
On the '020, assuming you use the 8 data registers, moving 8 long words via
a pair of MOVEM.L instructions takes 80 clocks, best case. An unfolded loop
with 8 MOVE.L An+,An+ takes 56.
Doing the same thing on the 68000, the MOVEM.L's take 152 clocks and the
unfolded loop takes 160.
What about an unrolled loop of MOVEMs?
There is actually a very good reason for using -1 as the terminating
value in a DBcc. While it doesn't seem intuitive for some operations, the
main use of it is to count operations that manipulate data in a table.
Consider, if the termination was 0, you would not have to adjust the count,
but you would have to adjust the address of the table by either using a -1
offset, by loading 'table-1' into an address reg, or by loading the table
address into a reg and then adjusting it. Six of one, 1/24 gross of the
other.
Whenever I am using DBcc in a fixxed count loop, I write the count as
#count-1 for clarity, and to remind myself later that I knew what I was
doing at the time I wrote it.
My pet peeves with the DBcc are twofold. The first is the WORD
limitation, and the second is with the nomenclature that requires me to
have to think in terms of 'Decrement and Branch UNTIL cc'.
Most programmers take a long time to really get the hang of DBcc. Usually
they at first do not realize that the cc is not set as a result of the
count in the loop register going negative, or if they do, they do not
realize the implications of that fact.
I still think they should have gone with 0 termination. That way the count
would always be correct and a loop parameter would only be decremented when
it was needed. You could also use pre-decrement to take care of it then,
as now. But it's all a moot point, as the instruction is cast in stone now.
That in mind, I did like your method of using "count-1" for the register
load, a lot less irritating than setting the to a low figure. Old habits
die hard.