Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
NOT trouble...
#1
I think this is a small bug:

Code:
DIM byte1 AS  BYTE
DIM byte2 AS UBYTE

byte1 = 15
byte2 = 15

' This prints -16 which is correct
print NOT byte1

'but this prints 4294967280, should be 240?
print NOT byte2
Reply
#2
Might be NOT returns a 32bit value...

What happens if you do:
byte2 = NOT byte2?
Reply
#3
If the result is stored into another byte the result will be the same.

Bitwise and logical operators are the same in BASIC, byte vars are converted to integer's before any operation is done, depending if signed or not the result will be an signed or unsigned integer.
Reply
#4
Isnt that wasteful?

Would there be some way to make it work with the larger of the types?


Like:
byte = NOT integer
Would work with integer

ushort = NOT ubyte
Would work with ushort

Or would that slow it down?

It probably would...

Dont mind me, im just thinking out loud..
Reply
#5
Every compiler i know does that, mainly because the x86 architecture that is so screwed (ie, the EDI and ESI registers have no byte versions).

Operations on short's are not converted to integers, but that doesn't mean it will be faster, as modern CPU hate 16-bit operations and prefixes (a prefix is needed on each 16-bit opcode in 32-bit pmode like it was needed to use 32-bit opcodes in real-mode).
Reply
#6
K, thanx that explains it

Is it only BYTE/UBYTE which is converted to a integer value, or doesit also effect other numeric data types?

Edit:
Something I just discovered, fb dosent seem to care if a sub in a included *.bi file is declared, but wont compile if I try to do the same in my main bas file..
Why is it so that you don't have to declare subs in *.bi files?

Edit2:

This crashes in fb
open "test.txt" for binary as #1
put #1, , 0
close #1

Would be better if you get a compile error like in qb, saying "expected variable"
Reply
#7
did you include the .bi before your executable code? if you place a sub before its called, you dont need previous declaration
Reply
#8
Aha! Thanx
Reply
#9
Alright, fixed, numeric literals won't be allowed with PUT # anymore, due the way byref as any arguments pass literal values to be VB compatible..
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)