25 Jan
2008
25 Jan
'08
10:52 a.m.
On 25 Jan 2008 at 12:00, cctalk-request at classiccmp.org wrote:
I figure that one might do part of the multiplication
and then
right shift the result some since were are going to truncate the
LSBs anyway. The first result is expected to error some. With
the correct value for the multiply, the error will always be on
the low side, keeping the error calculation simple. The largest
error seems to grow linearly so even with some truncation,
one should be able to hit 10K or so with only 1 or2 conditionals,
using a large fractional munber to multiply.
I don't think I'd ever use this but it was fun to think about.
I suspected that this is what you might be doing (that ADD HL,H
really had me wondering), but I wonder if your method will hold
together for accuracy or be faster than a simple unrolled 10 bit
divide. Remember that without the need for an iteration test you
can use BC to hold the scaled +10 and use a DAD instead of an SBC,
shaving a byte from the loop.
Cheers,
Chuck
25 Jan
25 Jan
9:20 p.m.
From: cclist at sydex.com
On 25 Jan 2008 at 12:00, cctalk-request at classiccmp.org wrote:
Hi
The ADD HL,H was a mistake. It should have been ADD HL,HL.
Here is my loopless and conditional less version:
; divides 0-799 by 10
; hl is input dividend
; a= qoutient
; h=remainder
Div10fast
ld d,h
lde,l
add hl,hl
add hl,hl
add hl,de
add hl,hl
ld b,h
ld c,l
add hl,hl
add hl,hl
add hl,bc
add hl,de
ld a,h ; add little more accuracy
add a,#16d ; tweak value
ld c,a
ld b,#0
add hl,bc
ld a,h ; quo*2
rra ; quo=a
ld l,a
ld c,a
ld h,b
add hl,hl
add hl,hl
add hl,bc
add hl,hl ; quo*10 to calc Remainder
ex de,hl
sbc hl,de ; l= remainder
ret
230 clock cycles and no conditionals
Dwight
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
I figure that one might do part of the
multiplication and then
right shift the result some since were are going to truncate the
LSBs anyway. The first result is expected to error some. With
the correct value for the multiply, the error will always be on
the low side, keeping the error calculation simple. The largest
error seems to grow linearly so even with some truncation,
one should be able to hit 10K or so with only 1 or2 conditionals,
using a large fractional munber to multiply.
I don't think I'd ever use this but it was fun to think about.
I suspected that this is what you might be doing (that ADD HL,H
really had me wondering), but I wonder if your method will hold
together for accuracy or be faster than a simple unrolled 10 bit
divide. Remember that without the need for an iteration test you
can use BC to hold the scaled +10 and use a DAD instead of an SBC,
shaving a byte from the loop.
Cheers,
Chuck
26 Jan
26 Jan
7:19 a.m.
From: dkelvey at hotmail.com
Hi
A couple minor errors in typing. See changes:
Hi
The ADD HL,H was a mistake. It should have been ADD HL,HL.
Here is my loopless and conditional less version:
; divides 0-799 by 10
; hl is input dividend
; a= qoutient
; h=remainder
Should be: ; l=remainder
Div10fast
ld d,h
lde,l
should be: ld e,l
add hl,hl
add hl,hl
add hl,de
add hl,hl
ld b,h
ld c,l
add hl,hl
add hl,hl
add hl,bc
add hl,de
ld a,h ; add little more accuracy
add a,#16d ; tweak value
ld c,a
ld b,#0
add hl,bc
ld a,h ; quo*2
rra ; quo=a
ld l,a
ld c,a
ld h,b
add hl,hl
add hl,hl
add hl,bc
add hl,hl ; quo*10 to calc Remainder
ex de,hl
sbc hl,de ; l= remainder
ret
230 clock cycles and no conditionals
Dwight
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
2:21 p.m.
It was thus said that the Great dwight elvey once stated:
230 clock cycles and no conditionals
Dwight
I came across this bit of code from http://www.hackersdelight.org/ to
divide by 10:
unsigned int div10(unsigned int n)
{
unsigned int q;
unsigned int r;
q = (n >> 1) + (n >> 2);
q = q + (q >> 4);
q = q + (q >> 8);
q = q + (q >> 16);
q = q >> 3;
r = n - ((q << 3) + (q << 1));
return (q + ((r + 6) >> 4);
}
On the Z80, the (q >> 8) is trivial to handle, and you can probably skip
the (q >> 16) statement all-to-gether (since you're only handling 16 bits
anyway, this reduces to 0 so the statement there can be skipped). My Z80
skills are pretty weak (and I don't have any references at hand right now)
but this looks pretty straight forward to translate.
-spc (In fact, the HackersDelight site is quite delightful)
7:45 p.m.
Date: Sat, 26 Jan 2008 17:21:56 -0500
From: spc at conman.org
To: cctalk at classiccmp.org
Subject: Re: Z80 Divide by 10
It was thus said that the Great dwight elvey once stated:
Hi
I coded this up in Forth and it does good at the divide.
The values q and r are not much good, meaning one still
has to calculate the remainder, similar to the last part of my
code.
The operation>> is really tough on a Z80 for 16 bit operations.
One needs to do thing through the a register and use rra instructions
or use the rr r instruction with a clearing of the carry before each
single bit shift. Not having a parameterized shift like the 386 has
makes it difficult.
I doubt one could beat the 230 cycles I had since each shift cost
12 cycles. This is 34 to 38 shifts depending on optimization or 408
cycles minimum without the 7 16 bit adds. This is already more
than the 230 cycles.
It might perform quite well on a machine with a native parameterize
right shift.
Dwight
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.?You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
230 clock cycles and no conditionals
Dwight
I came across this bit of code from http://www.hackersdelight.org/ to
divide by 10:
unsigned int div10(unsigned int n)
{
unsigned int q;
unsigned int r;
q = (n>> 1) + (n>> 2);
q = q + (q>> 4);
q = q + (q>> 8);
q = q + (q>> 16);
q = q>> 3;
r = n - ((q << 3) + (q << 1));
return (q + ((r + 6)>> 4);
}
On the Z80, the (q>> 8) is trivial to handle, and you can probably skip
the (q>> 16) statement all-to-gether (since you're only handling 16 bits
anyway, this reduces to 0 so the statement there can be skipped). My Z80
skills are pretty weak (and I don't have any references at hand right now)
but this looks pretty straight forward to translate.
8:12 p.m.
From: dkelvey at hotmail.com
I forgot to show my non-optimized Forth code:
: D10s ( n - q r Returned )
dup 2/
dup 2/ +
dup 2/ 2/ 2/ 2/ +
dup 2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/ +
( skipping the 16 shifts )
2/ 2/ 2/
swap over dup 2* 2* 2* swap 2* + -
2dup 6 + 2/ 2/ 2/ 2/ + ;
: TestD10s ( - ) ( prints results 0 to 799 )
( displays: n Returned r q )
800 0 do
i . i D10s . . . cr
i 20 mod 0=
if key drop cr then
loop ;
The Forth version I have does have a parameterized
shift but I wanted to code similar to what I'd deal with
in assembly. 2/ isn't unsigned on my Forth but for numbers
up to 800, that is no problem. I typed this in with indents
but hot mail strips leading spaces :(
Dwight
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.?You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
Date: Sat, 26 Jan 2008 17:21:56 -0500
From: spc at conman.org
To: cctalk at classiccmp.org
Subject: Re: Z80 Divide by 10
It was thus said that the Great dwight elvey once stated:
Hi
I coded this up in Forth and it does good at the divide.
The values q and r are not much good, meaning one still
has to calculate the remainder, similar to the last part of my
code.
The operation>> is really tough on a Z80 for 16 bit operations.
One needs to do thing through the a register and use rra instructions
or use the rr r instruction with a clearing of the carry before each
single bit shift. Not having a parameterized shift like the 386 has
makes it difficult.
I doubt one could beat the 230 cycles I had since each shift cost
12 cycles. This is 34 to 38 shifts depending on optimization or 408
cycles minimum without the 7 16 bit adds. This is already more
than the 230 cycles.
It might perform quite well on a machine with a native parameterize
right shift.
Dwight
230 clock cycles and no conditionals
Dwight
I came across this bit of code from http://www.hackersdelight.org/ to
divide by 10:
unsigned int div10(unsigned int n)
{
unsigned int q;
unsigned int r;
q = (n>> 1) + (n>> 2);
q = q + (q>> 4);
q = q + (q>> 8);
q = q + (q>> 16);
q = q>> 3;
r = n - ((q << 3) + (q << 1));
return (q + ((r + 6)>> 4);
}
On the Z80, the (q>> 8) is trivial to handle, and you can probably skip
the (q>> 16) statement all-to-gether (since you're only handling 16 bits
anyway, this reduces to 0 so the statement there can be skipped). My Z80
skills are pretty weak (and I don't have any references at hand right now)
but this looks pretty straight forward to translate.
27 Jan
27 Jan
12:35 a.m.
It was thus said that the Great dwight elvey once stated:
Where do you get 34 shifts from? I can see that being reduced down to
about 12 shifts:
/* q = (n >> 1) + (n >> 2) */
n >>= 1;
q = n;
n >>= 1;
q += n;
/* q = q + (q >> 4) */
q' = q;
q' >>= 1;
q' >>= 1;
q' >>= 1;
q' >>= 1;
q += q';
/* q = q + (q >> 8) */
q'(lo) = q(hi);
q(lo) += q'(lo);
q(hi) += CarryFlag;
/* q = q + (q >> 16) */
/* skipped because we're using 16 bits */
/* q = q >> 3 */
/* skipped because not needed */
/* r = n - ((q << 3) + (q << 1)) */
q' = q;
q' >>= 1;
q' >>= 1;
q += q'
r = n - q;
/* return q + ((r + 6) >> 4 */
r += 6;
r >>= 1;
r >>= 1;
r >>= 1;
r >>= 1;
q += r;
That's now 144 cycles for shifts, with 6 16 bit adds and two 8 bit adds.
Now that I have access to my Z80 references (but no real Z80 to test this
on), I think the following code will work:
;-------------------------------------
; DIV10 Perform division by 10
; Entry: BC - 16 bit value
; Exit: HL - quotient
; everything else trashed.
; If you need a remainder,
; then you can do
; REM = HL - ((HL << 3) + (HL << 1))
;------------------------------------
savehl defw 0
const6 defw 6
; bytes cycles
div10 ld d,b ; save n ; 1 4
ld e,c ; 1 4
; q = (n >> 1) + (n >> 2)
srl b ; 2 8
rr c ; 2 8
ld h,b ; 1 4
ld l,c ; 1 4
slr b ; 2 8
rr c ; 2 8
add hl,bc ; 1 11
; q = q + (q >> 4)
ld b,h ; 1 4
ld c,l ; 1 4
ld (savehl),hl ; 3 16
ld hl,savehl ; 3 10
and a ; 1 4
rrd ; 2 18
ld hl,(savehl) ; 3 16
add hl,bc ; 1 11
; q = q + (q >> 8)
ld b,0 ; 2 7
ld c,h ; 1 4
add hl,bc ; 1 11
; q = q + (q >> 16) skipped
; q = q >> 3 skipped
; r = n - ((q << 3) + (q << 1))
ld b,h ; 1 4
ld c,l ; 1 4
srl b ; 2 8
rr c ; 2 8
srl b ; 2 8
rr c ; 2 8
add hl,bc ; HL = q ; 1 11
ld b,h ; BC also = q ; 1 4
ld c,l ; 1 4
ex de,hl ; HL = n, DE = q; 1 4
or a ; CF = 0 ; 1 4
sbc hl,de ; n - q ; 2 15
; return q + ((r + 6) >> 4
ld de,(const6) ; 4 20
add hl,de ; 1 11
ld (savehl),hl ; 3 16
ld hl,savehl ; 3 10
and a ; 1 4
rdd ; 1 18
ld hl,(savehl) ; 3 16
add hl,bc ; 1 11
ret ; 1 10
;67 362
Well ... crap. 362 cycles. The Z80 really *sucks* on rotates, doesn't
it? I thought the RDD instruction would help, but really, it just breaks
even on the cycle count over four repetitions of SLR/RR (at least, the way
I've coded it because of the bottleneck in the use of HL).
-spc (Fun exercise though ... )
Date: Sat, 26 Jan 2008 17:21:56 -0500
From: spc at conman.org
To: cctalk at classiccmp.org
Subject: Re: Z80 Divide by 10
It was thus said that the Great dwight elvey once stated:
Hi
I coded this up in Forth and it does good at the divide.
The values q and r are not much good, meaning one still
has to calculate the remainder, similar to the last part of my
code.
The operation>> is really tough on a Z80 for 16 bit operations.
One needs to do thing through the a register and use rra instructions
or use the rr r instruction with a clearing of the carry before each
single bit shift. Not having a parameterized shift like the 386 has
makes it difficult.
I doubt one could beat the 230 cycles I had since each shift cost
12 cycles. This is 34 to 38 shifts depending on optimization or 408
cycles minimum without the 7 16 bit adds. This is already more
than the 230 cycles.
230 clock cycles and no conditionals
Dwight
I came across this bit of code from http://www.hackersdelight.org/ to
divide by 10:
unsigned int div10(unsigned int n)
{
unsigned int q;
unsigned int r;
q = (n>> 1) + (n>> 2);
q = q + (q>> 4);
q = q + (q>> 8);
q = q + (q>> 16);
q = q>> 3;
r = n - ((q << 3) + (q << 1));
return (q + ((r + 6)>> 4);
}
On the Z80, the (q>> 8) is trivial to handle, and you can probably skip
the (q>> 16) statement all-to-gether (since you're only handling 16 bits
anyway, this reduces to 0 so the statement there can be skipped). My Z80
skills are pretty weak (and I don't have any references at hand right now)
but this looks pretty straight forward to translate.
1:06 a.m.
It was thus said that the Great Sean Conner once stated:
ld b,h ; 1 4
ld c,l ; 1 4
srl b ; 2 8
rr c ; 2 8
srl b ; 2 8
rr c ; 2 8
add hl,bc ; HL = q ; 1 11
ld b,h ; BC also = q ; 1 4
ld c,l ; 1 4
ex de,hl ; HL = n, DE = q; 1 4
or a ; CF = 0 ; 1 4
sbc hl,de ; n - q ; 2 15
; return q + ((r + 6) >> 4
ld de,(const6) ; 4 20
add hl,de ; 1 11
ld (savehl),hl ; 3 16
ld hl,savehl ; 3 10
and a ; 1 4
rdd ; 1 18
ld hl,(savehl) ; 3 16
add hl,bc ; 1 11
ret ; 1 10
I find it amazing that there's an instruction set even more annoying than
the 8086 (segments and all). I was amazed at the lopsidedness of the
instruction set. I'm beginning to think I was lucky in skipping this
particular chip (my first 8-bit was the 6809, so I think I got spoiled).
There doesn't even seem to be an easy way to get the stack pointer, and the
only way I can see of doing it is:
or a
sbc hl,hl
add hl,sp
and no real good way of indexing the stack.
Sheesh.
-spc (What an ... interesting chip ... )
8:58 a.m.
Sean Conner said:
[...]
I find it amazing that there's an instruction
set even more annoying
than
the 8086 (segments and all). I was amazed at the lopsidedness of the
instruction set. I'm beginning to think I was lucky in skipping this
particular chip (my first 8-bit was the 6809, so I think I got spoiled).
There doesn't even seem to be an easy way to get the stack pointer, and
the
only way I can see of doing it is:
or a
sbc hl,hl
add hl,sp
and no real good way of indexing the stack.
Move HL to IX or IY on the Z80 and you can have normal indexing. No
autoincrement and -decrement though, so no real push/pop and IX,IY are
just index registers, not stacks.
--
Holger
28 Jan
28 Jan
1:10 p.m.
I find it amazing that there's an instruction
set even more annoying than
the 8086 (segments and all). I was amazed at the lopsidedness of the
instruction set. I'm beginning to think I was lucky in skipping this
particular chip (my first 8-bit was the 6809, so I think I got spoiled).
Classic 8 bit chips are all about the quirks. In the case of the Z80,
the main quirk is that it's an 8080 hiding behind an assembly language
designed to lure you into thinking it's orthogonal. Optimizations of
these processors are all about knowing the quirks and your algorithm.
Since 10 fits into a single byte, when calculating the remainder, you
only need to calculate the lower byte. You know that r+6 is also
always going to fit into 1 byte, so you can drop the 16 bit math in
that case, too. If you stick with the 0-799 limit originally
discussed, you know that the quotient is a one byte quantity with zero
in the upper two bits, which may allow for further optimization. q
+ ((r + 6) >> 4) will always be less than 128. In this case q + ( r >
9 ) is probably faster anyway, even if you allow for the full range.
1:44 p.m.
> I find it amazing that there's an
instruction set even more annoying than
> the 8086 (segments and all). I was amazed at the lopsidedness of the
> instruction set. I'm beginning to think I was lucky in skipping this
> particular chip (my first 8-bit was the 6809, so I think I got spoiled).
Other than the goofy segment layout, what did you find "annoying" about
the 8086 instruction set? I'm curious, because I'm only familiar with
6809, 8080, 8086, and 68000 and I wouldn't describe any of them as
"annoying" (limited in some areas, yes, but I equate "annoying" with
"making me want to physically injure the chip designers").
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
2:14 p.m.
Jim Leonard wrote:
Other than the goofy segment layout, what did you find
"annoying" about
the 8086 instruction set? I'm curious, because I'm only familiar with
6809, 8080, 8086, and 68000 and I wouldn't describe any of them as
"annoying" (limited in some areas, yes, but I equate "annoying" with
"making me want to physically injure the chip designers").
Can we just shoot the designers of the 8086 and just leave it that. !?
2:36 p.m.
woodelf wrote:
Jim Leonard wrote:
But seriously -- why? I didn't find it all that horrible -- in fact, I
missed the string handling (REP MOVSW/STOSW/SCASW/etc.) on all the other
platforms I mentioned. If they truly deserve to be shot, I want to know
why :-)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
Other than the goofy segment layout, what did you
find "annoying"
about the 8086 instruction set? I'm curious, because I'm only
familiar with 6809, 8080, 8086, and 68000 and I wouldn't describe any
of them as "annoying" (limited in some areas, yes, but I equate
"annoying" with "making me want to physically injure the chip
designers").
Can we just shoot the designers of the 8086 and just leave it that. !? 
3:11 p.m.
> Can we just shoot the designers of the 8086 and
just leave it that. !?
On Mon, 28 Jan 2008, Jim Leonard wrote:
But seriously -- why? I didn't find it all that
horrible -- in fact, I
missed the string handling (REP MOVSW/STOSW/SCASW/etc.) on all the other
platforms I mentioned. If they truly deserve to be shot, I want to know
why :-)
Some people get rather upset at the lack of symmetry, and lack of certain
instructions that might be handy, such as a load immediate into segment
registers.
3:35 p.m.
Fred Cisin wrote:
Hm... Yeah, I guess that was a hassle. 808x you have to:
MOV AX,immed
MOV ES,AX
or
PUSH DS
POP ES
...etc. Still, two instructions vs. one isn't that big a deal; I got
used to it.
I guess the one annoying thing with 808x is that, 80286 and later, they
removed POP CS. So if you used that for tricks, it immediately dies on
anything other than an 808x.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
> Can we
just shoot the designers of the 8086 and just leave it that. !?
On Mon, 28 Jan 2008, Jim Leonard wrote:
But seriously -- why? I didn't find it all
that horrible -- in fact, I
missed the string handling (REP MOVSW/STOSW/SCASW/etc.) on all the other
platforms I mentioned. If they truly deserve to be shot, I want to know
why :-)
Some people get rather upset at the lack of symmetry, and lack of certain
instructions that might be handy, such as a load immediate into segment
registers.
6:14 p.m.
Some people get rather upset at the lack of symmetry,
and lack of certain
instructions that might be handy, such as a load immediate into segment
registers.
There certainly are problems, not the least of which is the "shift 4
and add" segmentation rather than "shift N and add" where N is 11, 12,
14, or 16. Of course 16 is the right answer now, but in 1977 there
were logical reasons to want 11, 12, or 14. Never could come up with
a good reason to choose 4 except to artificially limit the expansion
address space to 1MB.
Lack of load immediate into segment isn't a big problem. Lack of "add
immediate to effective address" is a much bigger problem.
6:35 p.m.
On Mon, 28 Jan 2008, Eric J Korpela wrote:
were logical reasons to want 11, 12, or 14. Never
could come up with
a good reason to choose 4 except to artificially limit the expansion
address space to 1MB.
"But why would anybody ever want more than 1MB of RAM?"
"But, if you activate A20, then you CAN go past 1MB!" (not very far)
29 Jan
29 Jan
7:35 a.m.
Eric J Korpela wrote:
Lack of load immediate into segment isn't a big
problem. Lack of "add
immediate to effective address" is a much bigger problem.
Isn't that handled by ADD SI,immed?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
30 Jan
30 Jan
10:09 a.m.
On Jan 29, 2008 7:35 AM, Jim Leonard <trixter at oldskool.org> wrote:
Eric J Korpela wrote:
That adds an immediate value to the offset portion of an effective
address without changing the segment portion. There should have been
an ADD DS:SI,immed instruction. To do long pointer arithmetic you
end up doing something like...
MOV AX,DS
ADD SI,immed
MOV BX, SI
MOV CL, 4
SAR BX,CL
ADD AX,BX
AND SI,0Fh
MOV DS,AX
Lack of load immediate into segment isn't a
big problem. Lack of "add
immediate to effective address" is a much bigger problem.
Isn't that handled by ADD SI,immed?
28 Jan
28 Jan
3:13 p.m.
Jim Leonard wrote:
Make a list A: 6809 B: 8086
See Answer:
That is not quite fair for Intel since the 6809 came out after
the 8086. The problem is you have a 16 bit design crippled
so you can be 8080A software comptable.
My personal bias is the pre-fetch buffer, you never know just
what speed your cpu is running at. I find both the Z80 and
8086 not clean as they tweek the 8080A instruction set to something
that is almost usefull.
Can we just
shoot the designers of the 8086 and just leave it that. !?
But seriously -- why? I didn't find it all that horrible -- in fact, I
missed the string handling (REP MOVSW/STOSW/SCASW/etc.) on all the other
platforms I mentioned. If they truly deserve to be shot, I want to know
why :-)
3:29 p.m.
woodelf wrote:
My personal bias is the pre-fetch buffer, you never
know just
what speed your cpu is running at.
Okay, I can see that. 8086 was 6 bytes, 8088 was 4 bytes, NEC V20/V30
was 6, 80286 was 8 bytes, 80386 was 16 bytes, etc. I suppose it was
good that (in the IBM PC, anyway) we had a 1.193181 MHz timer to play
with, yes? At least that wasn't variable...
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
4:35 p.m.
It was thus said that the Great Jim Leonard once stated:
Me? I didn't find it all that odd (at least, once I realized it was
better to look at the opcode map in octal instead of hex), but I do recall
reading various rants against the x86 on USENET in the early to mid 90s. I
did *a lot* of 8086 programming in the late 80s/early 90s, and still like
revisiting it from time to time (well, assembly in general, not specifically
the 8086).
-spc (Man, I think I'd prefer the 6502 over the Z80 any day, and I hate
the 6502 ... )
> I find it
amazing that there's an instruction set even more annoying
> than
>the 8086 (segments and all). I was amazed at the lopsidedness of the
>instruction set. I'm beginning to think I was lucky in skipping this
>particular chip (my first 8-bit was the 6809, so I think I got spoiled).
Other than the goofy segment layout, what did you find "annoying" about
the 8086 instruction set?
27 Jan
27 Jan
7:40 a.m.
From: spc at conman.org
It was thus said that the Great dwight elvey once stated:
Where do you get 34 shifts from? I can see that being reduced down to
about 12 shifts:
Hi
I hadn't done any byte swapping optimization and counted each
register shift to be a shift, so each 16 bit shift cost 2 register shifts.
Right shift is expensive on the Z80. It could be a little better if
we had a shift that didn't include carry like the left shift.
I think my routine may be extended a few bytes by changing the
tweak value. It has greater effect for small values but could get one
or two numbers increased if optimized.
Such tweaks are there to make up for the way we truncate instead
of rounding. It means the value is always too small after a large number
of operation.
The larger numbers are effected more by the number of times we
do the shifts. Since the algorithm was designed for the maximum
range, we might do better by removing one of the steps and
changing the tweak value a little. This may improve you code
some. Mine is already reduces to the minimum because the
tweak value only effect the low end the most.
Where and when in the calculation one does the tweaks my
improve things as well. The rounding effect my be greatest
at one step over some other step.
I think us bit twittlers are enjoying the exercise. It is surely
bringing back all the math I though I'd lost.
Dwight
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail?-get your
"fix".
http://www.msnmobilefix.com/Default.aspx
Date: Sat, 26 Jan 2008 17:21:56 -0500
From: spc at conman.org
To: cctalk at classiccmp.org
Subject: Re: Z80 Divide by 10
It was thus said that the Great dwight elvey once stated:
Hi
I coded this up in Forth and it does good at the divide.
The values q and r are not much good, meaning one still
has to calculate the remainder, similar to the last part of my
code.
The operation>> is really tough on a Z80 for 16 bit operations.
One needs to do thing through the a register and use rra instructions
or use the rr r instruction with a clearing of the carry before each
single bit shift. Not having a parameterized shift like the 386 has
makes it difficult.
I doubt one could beat the 230 cycles I had since each shift cost
12 cycles. This is 34 to 38 shifts depending on optimization or 408
cycles minimum without the 7 16 bit adds. This is already more
than the 230 cycles.
230 clock cycles and no conditionals
Dwight
I came across this bit of code from http://www.hackersdelight.org/ to
divide by 10:
unsigned int div10(unsigned int n)
{
unsigned int q;
unsigned int r;
q = (n>> 1) + (n>> 2);
q = q + (q>> 4);
q = q + (q>> 8);
q = q + (q>> 16);
q = q>> 3;
r = n - ((q << 3) + (q << 1));
return (q + ((r + 6)>> 4);
}
On the Z80, the (q>> 8) is trivial to handle, and you can probably skip
the (q>> 16) statement all-to-gether (since you're only handling 16 bits
anyway, this reduces to 0 so the statement there can be skipped). My Z80
skills are pretty weak (and I don't have any references at hand right now)
but this looks pretty straight forward to translate.
2:48 p.m.
dwight elvey wrote:
I think my routine may be extended a few bytes by
changing the
tweak value. It has greater effect for small values but could get one
or two numbers increased if optimized.
Such tweaks are there to make up for the way we truncate instead
of rounding. It means the value is always too small after a large number
of operation.
Dwight, if my test-code version of your routine is correct, the constant
correction can be reduced to 1 from 16 and the routine then fails at 1280
instead of 1210. The addition can now be changed to an increment and some other
register optimisation done to take another two bytes and some cycles off (no
need to use A any longer, quotient is in C):
------------------------------
Segment: MAIN
base=$0000 end=$001D bytes=30
* 0-799 divided by 10
* implements: quo = ( 51*x + (51*x/256+1) ) / 512
* rem = x - (q*4+q)*2
* hl = dividend
* Returns:
* c = quotient
* l = remainder
machine z80
0000 54 Div10fast LD D,H de = hl
0001 5D LD E,L
0002 29 ADD HL,HL
0003 29 ADD HL,HL
0004 19 ADD HL,DE x * 5
0005 29 ADD HL,HL x * 10
0006 44 LD B,H bc = 10x
0007 4D LD C,L
0008 29 ADD HL,HL
0009 29 ADD HL,HL
000A 09 ADD HL,BC x * 50
000B 19 ADD HL,DE hl = x*50 + x
000C 06 00 LD B,0 bc = hl/256
000E 4C LD C,H
000F 03 INC BC + 1
0010 09 ADD HL,BC ADD little more accuracy
0011 4C LD C,H c = hl / 256 / 2
0012 CB 19 RR C quo = c, carry cleared in ADD
0014 60 LD H,B hl = quo
0015 69 LD L,C
0016 29 ADD HL,HL quo*10 to calc RemainDEr
0017 29 ADD HL,HL
0018 09 ADD HL,BC
0019 29 ADD HL,HL
001A EB EX DE,HL
001B ED 52 SBC HL,DE rem = l
001D C9 RET
------------------------------
2:54 p.m.
On Sunday 27 January 2008 10:40, dwight elvey wrote:
I think us bit twittlers are enjoying the exercise.
It is surely
bringing back all the math I though I'd lost.
I've not contributed much to this thread, but I *am* enjoying the reading of
it, particularly when more than one way of attacking the problem with
various tradeoffs in mind get into the mix. :-)
Just FWIW...
--
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
9:06 a.m.
/* q = q >> 3 */
/* skipped because not needed */
/* r = n - ((q << 3) + (q << 1)) */
q' = q;
q' >>= 1;
q' >>= 1;
q += q'
r = n - q;
You give no justification for the algorithm change here ((q>>3)<<3 is
not, in general, equal to q). Did you just test and find it worked for
the argument range of interest, or what?
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:16 p.m.
It was thus said that the Great der Mouse once stated:
I saw
q >> 3
q << 3
And figured it wasn't needed. But you're right, it's not quite the same,
but I would think that:
/* q = q >> 3 */
/* shift skipped because not needed */
/* r = n - ((q << 3) + (q << 1) */
q' = q & ~3;
q' >>= 1;
q' >>= 1;
q += q'
r = n - q;
But as I did the work, I found out that this wasn't all that great on a
Z80 anyway, even if it did work as I wrote it.
-spc
/* q = q
>> 3 */
/* skipped because not needed */
/* r = n - ((q << 3) + (q << 1)) */
q' = q;
q' >>= 1;
q' >>= 1;
q += q'
r = n - q;
You give no justification for the algorithm change here ((q>>3)<<3 is
not, in general, equal to q). Did you just test and find it worked for
the argument range of interest, or what?
8:14 p.m.
I saw
q >> 3
q << 3
And figured it wasn't needed. But you're right, it's not quite the
same, but I would think that:
[...]
q' = q & ~3;
& ~7... :-)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
11:26 p.m.
It was thus said that the Great der Mouse once stated:
Um ... yeah. I was thinking "three bits" and well ...
-spc (I got confused by all those threes ... )
I saw
q >> 3
q << 3
And figured it wasn't needed. But you're right, it's not quite the
same, but I would think that:
[...]
q' = q & ~3;
& ~7... :-)
6176
days inactive
6181
days old
28 comments
11 participants
participants (11)
-
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
dkelvey＠hotmail.com -
hilpert＠cs.ubc.ca -
holger.veit＠iais.fraunhofer.de -
korpela＠ssl.berkeley.edu -
mouse＠Rodents.Montreal.QC.CA -
rtellason＠verizon.net -
spc＠conman.org -
trixter＠oldskool.org