home .. forth .. colorforth mail list archive ..

Re: [colorforth] bug in bit32?

On Fri, 6 May 2005, Albert van der Horst wrote:


On Thu, May 05, 2005 at 07:25:08PM -0400, Mark Slicker wrote:

On Fri, 6 May 2005, Albert van der Horst wrote:

<SNIP>


I don't follow this analysis. You should probably review again the source
code. The way bit16 works is that is will shift the bits one by one into
the carry bit, if the carry bit is set it will write a pixel. I does this
16 times. bit32 is similar execpt it will write four pixels if the carry
bit is set.


You're right I was totally off the mark. I overlooked that
the LODS instruction sets a new value into AX.
But that establishes that the high 16 bits of AX are never inspected
in the loop of bits15 and bits32.
This is not entirely correct, remember that bit32 shifts EAX for each iteration, and bit16 shifts just AX. This is where I argue that bit32 has a bug, since the carry should be tested on the shift of AX. 

I don't know if it helps but I've coded bit16 in colorForth:

: bit16 w drop *byte 15 2*s 16 for 2* -if p! then 2 +i next ;
I might change some names here, but the idea is similar, I use sign bit instead of the carry bit since colorForth has -if . 

w is the pentium word prefix
*byte swaps the lower bytes of T
p! writes DX to (EDI)
+i adds a literal to EDI
I've recoded some words so 'bit16' does not use the data stack, except for 'w drop' which fetches the next row of the bitmap. 


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com