Re: 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.