Page 1 of 1

Domain range checking for bitwise operators

Posted: 22 Apr 2021 1:20
by choibakk
I ran into an issue using the "~~" operator that I have distilled into a simple example question (VP10-64 bit):

In C++, I can do something like this:

Code: Select all

int main() {     unsigned char v1 = 0xff;     unsigned char v2 = ~v1 + 0x1;     printf("%d\n", v2); }
In prolog I'm wondering if the following range checking is intended. Consider the following compiler error (or is this a domain issue?):

Code: Select all

        hasDomain(unsigned8, V1),         hasDomain(unsigned8, V2),         V1 = 0xff,         V2 = ~~V1, % --> The value 4294967040 is out of the range [ 0 .. 255 ] for the domain 'core::unsigned8'         V3 = V2+1,         stdio::writef("%x\n", V3),
Thanks,
choibakk

Re: Domain range checking for bitwise operators

Posted: 22 Apr 2021 11:31
by Martin Meyer
I think the answer is (Thomas may correct me): The Language Reference says that the operators for bitwise operations are declared (only) on unsigned, unsigned64, and unsignedNative arguments.

When an unsigned8 argument is supplied to the NOT operator it will be converted to the 'best-fitting' domain, thus it will be converted to unsigned. The result of ~~V1, where V1 is of domain unsigned and has value 0, exceeds of course the limits of unsigned8.

To make NOT work with unsigned8 and unsigned16 the upper three resp. two bytes of the result must be zeroed. For example:

Code: Select all

class predicates     not8 : (unsigned8 X) -> unsigned8 NotX. clauses     not8(X) = ~~X ** 0xFF.   clauses     run() :-         stdIo::write(not8(1)).

Re: Domain range checking for bitwise operators

Posted: 22 Apr 2021 21:42
by choibakk
Martin,

I had stepped through to see the domain change and the FFFFFF in the upper bytes. Thanks for the clarification on the documentation--I had completely overlooked that line. I hope in the future unsigned8 will be supported as well.

Thanks,
choibakk