Bit shift bug. (*solved*)

[boriel]

Bit shift by 0, when 0 is from a variable=0, which is incorrect!

Code:

DIM num as uByte=1
DIM num2 as uByte=0

PRINT num
PRINT (num<<0)
PRINT (num<<num2)

All three lines should read "1"

Code:

    ld hl, (_num2 - 1)
    ld a, (_num)
    ld b, h
__LABEL0:
    add a, a
    djnz __LABEL0

Putting a byte through HL is a bit inefficient (as opposed to ld a,(_num2) / ld b,a / ld a,(_num)- but I see the heart of the problem. DJNZ decreases first (to 255) then loops if not zero. So this does 256 bit shifts before releasing - making the result bit shift right off the top of the byte value. Not trivial to solve this and still be efficient, however. Looks like it might need a CP test

I like how var<<0 is completely ignored to just print var though - very nice coding for that constant. Same code as the line above.

Yes, I supposed this was the problem. Anyway, the rule of thumb is that from the BASIC programmer point of view expr << 0 and expr << var must return the same result when 'var' = 0, as you pointed.

I could rearrange the instructions above, in the backend, to produce this:

Code:

; Loads a and h in reverse order so, a = number of shift iterations
; h = expression to shift
   ld a, (_num2 - 1)
    ld hl, (_num)
   or a ; a = 0?
   jr z, __LABEL1 ; a = 0 => No loop
    ld b, a ; Loads counter into b
   ld a, h ; Loads expression into a
__LABEL0:
    add a, a
    djnz __LABEL0
__LABEL1:

Will try to apply this patch this evening. Also, can you check if this bug happens with Uinteger and with Ulong, please?