Improved bAND, bOR, bXOR

[britlion]

Here are more general purpose functions for AND, OR and NOT. They work with Byte, Integer or Long types (the function is long, but the cast works upscale).

A binary NOT is tougher - what bits do you invert? If you send me 8, and I invert 32 is that what you wanted?
(of course, you could bAND the result into the last 8 or 16 bits)

These functions are very similar, of course.

Binary AND:

Code:

Function bAND(a as uLong, b as uLong) as uLong
asm
    
    POP BC ; something
    EXX
    POP HL ; return address
    EXX
    POP HL ; aL
    POP DE ; aH
    POP BC ; bL
    
    LD A,B
    AND H
    LD H,A
    
    LD A,C
    AND L
    LD L,A
    
    POP BC ;bH
    
    LD A,B
    AND D
    LD D,A
    
    LD A,C
    AND E
    LD E,A
    
    EXX
    PUSH HL ; put return address back
    EXX
            
end asm
END function

Binary OR:

Code:

Function bOR(c as uLong, d as uLong) as uLong
asm
    
    POP BC ; something
    EXX
    POP HL ; return address
    EXX
    
    POP HL ; aL
    POP DE ; aH
    POP BC ; bL
    
    LD A,B
    OR H
    LD H,A
    
    LD A,C
    OR L
    LD L,A
    
    POP BC ;bH
    
    LD A,B
    OR D
    LD D,A
    
    LD A,C
    OR E
    LD E,A
    
    EXX
    PUSH HL ; put return address back
    EXX      
end asm
END function

Binary XOR:

Code:

Function bXOR(e as uLong, f as uLong) as uLong
asm
    
    POP BC ; something
    EXX
    POP HL ; return address
    EXX
    
    POP HL ; aL
    POP DE ; aH
    POP BC ; bL
    
    LD A,B
    XOR H
    LD H,A
    
    LD A,C
    XOR L
    LD L,A
    
    POP BC ;bH
    
    LD A,B
    XOR D
    LD D,A
    
    LD A,C
    XOR E
    LD E,A
    
    EXX
    PUSH HL ; put return address back
    EXX        
end asm
END function

Here's the 32 bit NOT function. This is the one that's tricky. If you want a NOT in 8 bits, do bAND(255,bNOT32(num)) - in other words, AND it to cut the length you want; or you are going to be confused at the result being a LOT bigger than you wanted.

8 bit result: bAND with 255
16 bit result: bAND with 65535

If you want the function, it's probably obvious to you. You could also use bNOT16 and bNOT8 listed in the previous thread - and if you always want 16 or 8 bit values, that's the smaller and faster route.

32 Bit Binary NOT:

Code:

FUNCTION FASTCALL bNOT32(g as uLong) as uLong
asm
   LD A,D
   CPL
   LD D,A
  
   LD A,E
   CPL
   LD E,A
  
   LD A,H
   CPL
   LD H,A
  
   LD A,L
   CPL
   LD L,A
end asm
END FUNCTION

[boriel]

Here are more general purpose functions for AND, OR and NOT. They work with Byte, Integer or Long types (the function is long, but the cast works upscale).

A binary NOT is tougher - what bits do you invert? If you send me 8, and I invert 32 is that what you wanted?
(of course, you could bAND the result into the last 8 or 16 bits)

These functions are very similar, of course.

Here's the 32 bit NOT function. This is the one that's tricky. If you want a NOT in 8 bits, do bAND(255,bNOT32(num)) - in other words, AND it to cut the length you want; or you are going to be confused at the result being a LOT bigger than you wanted.
[...]

32 Bit Binary NOT:

Code:

FUNCTION FASTCALL bNOT32(g as uLong) as uLong
asm
   LD A,D
   CPL
   LD D,A
  
   LD A,E
   CPL
   LD E,A
  
   LD A,H
   CPL
   LD H,A
  
   LD A,L
   CPL
   LD L,A
end asm
END FUNCTION

This code is already implemented in the library-asm directory (see neg32.asm).
In fact, bitwise operators were planned a long time ago, but I won't add new features until the compiler bugs are completely fixed.
You should not try to implement this code (I have already done so, in a separated file!), because they won't be functions, but operators. The compiler will insert them inline, which is faster than a function call, so instead of: bAND(X, Y) you will do X bAND Y.

I already have the code for integers (of any size) bitwise operators, and I think It's quite optimal. :!:
So, It's better to wait until it is released, and then try to optimize it by looking at librayasm/ directory.

[britlion]

I can't offhand see how this code could be optimised further, honestly. I'd be curious and intrigued to see what clever tricks could be pulled, though.

This code is already implemented in the library-asm directory (see neg32.asm).

Oh wait, you're just talking abot NOT?

I had a look at that. That's a two's complement negation, which isn't quite the same - it adds 1 :-) But yes, it does it exactly the same way. I
In fact come to think of it:

Code:

FUNCTION bNOT32 (a as long) as long
return (-a)+1
END FUNCTION

ought to call your code and do the same thing, yes? The downside is it has to deal with long, not uLong - and usually programmers playing with bitwise operations want unsigned integers so they can just think of them as bits, not values.


[and referring to and/or/not]
I know you planned to put them in as full fledged operators, with bAND == &, but I revisited this as a temporary measure because

1> I hated the original ones I did - they were a kludge using fastcall, because I hadn't worked out how to do stdcall at all. (And I'm still not sure I'm doing it right)

2> I got the feeling there was a need for them (read as: I needed them, and thought I should share) until they were put into the main code; which I thought might be a while.

So, at least until something better comes along, I figured these wouldn't be bad.

[boriel]

I can't offhand see how this code could be optimised further, honestly. I'd be curious and intrigued to see what clever tricks could be pulled, though.

Well, I didn't explain clearly: because they are PART OF the language; the code is the same (bitwise operations will be straighforward). So the code is placed *inline*, so no function call, no push/pop sequence (whenever possible), and availability for all integer types. :!: (8, 16 and 32 bits). :wink:

There will be also a XOR logical operator, so this:

Code:

IF (a < b) AND NOT(b < c) OR NOT (a < b) AND (b < c) THEN
[...]
END IF

can be written as:

Code:

IF (a < b) XOR (b < c) THEN
[...]
END IF

which will be faster, shorter and take less memory.
So the language will be completely orthogonal.

[britlion]

Very nice!