Mathematical question

[Thaddy]

He simply means that bits are bits, Not flags.

[Fibonacci]

these bitwise operations, they are wrong.

Can you elaborate please?

Just look at the second screenshot. "-1" manipulated as Integer vs Multi_Int_XV. Integer is OK, Multi_Int_XV produces wrong result.

Edit: Sorry, I forgot to mention I commented out the exception code in the unit Just that disallowing bitwise operations on negative values is wrong. It shouldnt be checked at all if its negative or positive.

Possible solutions:
1) Dont store "NEGATIVE" boolean flag, instead store "SIGNED" flag
2) Separate types for signed and unsigned

[paule32]

but Bit's can be Flag's:

o o o o o o o o  <--- Flag's (all set)  => 255
7 6 5 4 3 2 1 0  <--- Bit's (Position)

=>

o       o o o    o  <--- Flag's (not all set) - can be use for: (Carry Flag, ..)
7 6 5 4 3 2 1 0  <--- Bit's

[ad1mt]

Just that disallowing bitwise operations on negative values is wrong. It shouldnt be checked at all if its negative or positive.

I still don't understand what the problem is.
To make it work, the programmer just has to do ABS on the value, like this:

Code: Pascal  [Select][+][-]

1. V:= Abs(W) << 1;

However, if the programmer inadvertently tries to do a bitwise operation on a negative value, and would want that to be flagged as invalid, then what I'm doing is correct.
If I "fix" the programmer's error, by doing an implicit ABS, that might not be what the programmer wanted, and could cause problems later like undiscovered bugs.
The way I am doing it means the programmer has control.

[Fibonacci]

So if I want to change 1 bit, you suggest to first call Abs() on the value?

[paule32]

for usually, I use Assembly Code for that.
You can then do:

asm
  mov al, 0b   ; set first (0) bit to AL register
  mov al, 1b   ; set first (1) bit to AL register

  mov al, 10b ; set second bit (1) to AL register, and first bit (0) <-- remark's
end;

remarks:
00 = 0
01 = 1
10 = 2

so:
asm mov al, 10b  end;  is the same as:
asm mov al, 0x02 end;

you can check the flag with:  JZ = Jump Zero (0), ...

asm
@start:
  mov al, 00b
  jz @zero
  ; do something, if not zero
@zero:
  ; do something else, if AL is zero
end;

[Thaddy]

That is fine on 8 bit computers but is slow on anything else.

[paule32]

This was only an Example.
It give even more Menomic's like:
ADC = Adjust Carry.

modern IBM compatible PC's have these old Instruction Set's for backward compatible
with more or lesser complex other Menomic's.

So, modern PC's are indeed very slow - in Context of RISC CPU's.
Because:
AL/AH will be store into AX
AX   will be store into EAX, and
EAX will be store into RAX

This have to do with the Bandwidth of the BUS System.

[Fibonacci]

@paule32: We are talking about Multi_Int_XV type here, not simple integers.


11111111111111111111111111111111 <- this is Integer(-1)
00000000000000000000000000000001 <- this is Abs(Integer(-1))

So should I call Abs() before doing bitwise operations? I guess not.

If I want to change the sign, I can do it like this:
int := int xor (1 shl 31)

If the type is not Integer but Multi_Int_XV, I cant do this because "you cant do bitwise operations on negative values". Of course if I first call Abs() on the value, it will work, but the value will be completely wrong.

@ad1mt: Again, you can know the real decimal value of the "bits" only if you know how to treat the bits, as signed or not. Currently you store a boolean flag to tell if this value is "negative" or not. Instead, you should store if its SIGNED or not. Bitwise operations operate on bits, the decimal value doesnt matter, if negative, above 100, equal to 33 or whatever.

I didnt read all the code in your 15k LOC unit, I dont know how it actually works. The "decimal value" when returned as String should be built knowing if the expected value is signed or unsigned, not if its negative or not.

Also I dont know why changing 1 bit (the most significant bit in 32bit value) causes "overflow" exception when converting it back to 4 byte Integer.

Code: Pascal  [Select][+][-]

1. var
2.   i: integer;
3.   m: Multi_Int_XV;
4. begin
5.   i := 1;
6.   m := i; // 4 bytes
7.   m := m xor (1 shl 31); // still 4 bytes
8.   i := m; // overflow exception, but its still 4 bytes

If I touch the "sign bit", its overflow.

[paule32]

For Decision's, on negative or positive Number's, I use a Remainder carry Flag.
So, in these there, you have three Options with two Bit's

if carry = 00b then // do positive Action's for unsigned Value's
if carry = 01b then // do negative Action's for signed Value's
if carry = 10b then // abs(carry)  // then carry is always "unsigned"

All is depend on you Application Logic, and Goal.
With the Option's above, you ship around the Limit's of some Type's.

So, you can have a the Size of a signed DWORD like -4 GB, and +4 GB instead only: -2 GB, and +2GB.

Okay, this have a little payload.
But this was only a thinking over Idea from me ...

[Thaddy]

This have to do with the Bandwidth of the BUS System.

No it has to do with the native width of the processor.
There are efficient instructions, though, on e.g. Intel, like movb and family, to handle byte sized instructions.
You should use those.

[paule32]

I am not a Friend of AT&T Assembly Style like:
movb

I loved, and prefer Intel Assembly Style like:
mov byte ptr

mov.b sounds like Motorolla 68k Assembly for me

[marcov]

you can check the flag with:  JZ = Jump Zero (0), ...

asm
@start:
  mov al, 00b
  jz @zero

Afaik mov doesn't affect the flags, so this code doesn't look so good.

Binary notation for literals is a % in FreePascal, hex is $ and octal is &, all prefixes and including its assembler syntax.

[paule32]

you right.
To correct this:

mov al, 0
cmp al, 0
jz @zero
...

Intel nasm differs from AT&T gas:

Intel:  mov eax, 1        (dst <- src)
AT&T: movl $1, %eax  (src -> dst)

My fault - sorry.

inline: movl $1, %%eax

[ad1mt]

I dont know why changing 1 bit (the most significant bit in 32bit value) causes "overflow" exception when converting it back to 4 byte Integer.

Code: Pascal  [Select][+][-]

1. var
2.   i: integer;
3.   m: Multi_Int_XV;
4. begin
5.   i := 1;
6.   m := i; // 4 bytes
7.   m := m xor (1 shl 31); // still 4 bytes
8.   i := m; // overflow exception, but its still 4 bytes

I was worried that my code might have a bug; and I always welcome bug reports.
So I ran your code, to see what was going on.
After the XOR operation, m = 2147483649
32-bit integer type is signed, and can only accept values between -2,147,483,648 and 2,147,483,647
2147483649 is outside its range, so assigning m to i correctly causes overflow.
If you declare i to be unsigned integer (aka longword, aka uint32), then it works ok, because it can accept values from 0 to 4294967295