Byte Limitation?

Shannara · Post by **Shannara** » Sun Apr 11, 2004 3:05 am

Coming from VB, I always thought bytes was 0 to 255 (aka 256 bytes). While I was looking through the PB manual, it turns out, in VB, bytes in PB are, -128 to 127 ... what the... ? why is PB different? Im looking to take no more then 1 byte for data and have the number up to 255 .... how can I do this with out wasting a byte using a Word ?

Post by **Dare2** » Sun Apr 11, 2004 3:39 am

programmatically, this is one way.

Code: Select all

Procedure byteToWord(v.b)
  ProcedureReturn v & 255
EndProcedure

byt.b=255 : Debug Str(byt) + " : " + Str(byt & 255)
byt.b=128 : Debug Str(byt) + " : " + Str(byt & 255)
byt.b=127 : Debug Str(byt) + " : " + Str(byt & 255)

; or same deal with procedure to readability?

byt.b=255 : Debug Str(byt) + " : " + Str(byteToWord(byt))
byt.b=254 : Debug Str(byt) + " : " + Str(byteToWord(byt))
byt.b=128 : Debug Str(byt) + " : " + Str(byteToWord(byt))
byt.b=127 : Debug Str(byt) + " : " + Str(byteToWord(byt))
byt.b=1 : Debug Str(byt) + " : " + Str(byteToWord(byt))
byt.b=0 : Debug Str(byt) + " : " + Str(byteToWord(byt))

If your concern is storage within, say, a file. Still a long (in above eg) when in use.

Shopro · Post by **Shopro** » Sun Apr 11, 2004 8:35 am

Shannara:
I was confused with the same thing as well.

I wonder if both types(0 to 255, -128 to 127) can be added to PB?

-Shopro

Froggerprogger · Post by **Froggerprogger** » Sun Apr 11, 2004 10:32 am

It's just because that consequently all integer variable types are signed in PB.
Of course it would be fine to add the types unsigned byte/word/long, also (.ub, .uw, .ul) and I think it's on the ToDo-list for the paradisiac PB 4.0

Is it ?

So long the workaround:
(same as mentioned by Dare)

byte.b & $FF
word.w & $FFFF
long.l & $FFFFFFFF

Post by **Dare2** » Sun Apr 11, 2004 1:19 pm

Froggerprogger wrote:Is it ?

Hope so.

I know PB is pretty AR about program sizes, but this should not add much bloat.

If the info is stored in program it requires 1 bit per integer variable to signify signed or unsigned.

If there is a spare bit floating around in the internal variable control tables, great. No real cost in size.

If not, then another byte can be allocated and that allows another 7 bits for other useful variable info. Like type.

One byte per variable and a procedure to handle signed/unsigned is not going to bloat out most programs.

This could also be done at compile time, although this is not quite as robust nor is it get-at-able within a program. But if the compilation process knows what it is dealing with it can generate the necessary asm code without adding anything to internal variable controls. Not much extra bloat there.

So here's hoping!

Post by **Andre** » Sun Apr 11, 2004 1:31 pm

Fred already said "It will be done". I think, PB 4.0 should be true...

Some "technical" discussion took place here: viewtopic.php?t=6896&highlight=unsigned

Post by **Dare2** » Sun Apr 11, 2004 1:34 pm

Thats great.

Kale · Post by **Kale** » Sun Apr 11, 2004 3:42 pm

how can I do this with out wasting a byte using a Word?

Only people using PureBasic think this way! 8O

Shannara · Post by **Shannara** » Thu Aug 12, 2004 6:35 am

Since "it will be done"

If I did the following

Code: Select all

byte.b
byte = 155
byte & $FF

WriteByte(byte)

The above should only take 1 byte of hard disk space, right? Not 2? The reason Im asking is because it really really really pays to have very very small data files on HD, even though we have huge HDs, usually the smaller the file, the quicker it'll load.. (especially if you do expansions and such in memory).

Froggerprogger · Post by **Froggerprogger** » Thu Aug 12, 2004 10:08 am

Yes it will use only 1 Byte, but you don't need to write byte & $FF in your code.

WriteByte(155) and WriteByte(155 & $FF) results in the same bitstring.
(Because of $FF is %11111111 the bitstring is totally determinated by the bytenumber)

The $FF (or $FFFF for words) is only used to 'convert' a sigend byte (word) internally as unsigned to a signed long-value:

Code: Select all

b.b = 200
Debug b
Debug b & $FF

w.w = 40000
Debug w
Debug w & $FFFF

So you might use it for calculations, etc.
But the following will NOT work, because there's no greater type than long:

Code: Select all

l.l = $80000000
Debug l
Debug l & $FFFFFFFF

You cannot convert a signed long into an unsigned long.
But though here again, WriteLong($80000000) and WriteLong($80000000 & $FFFFFFFF) result in the same Bitstring.

blueznl · Post by **blueznl** » Thu Aug 12, 2004 4:08 pm

in many cases speed is more important than size., you'd have to do some testing, but i assume bytes, words and longs are all pretty much the same speed on modern hardware, in fact under certain conditions longs will be the fastest

instead of bothering about the variable sign and type, i use longs everywhere, only using other variables when there is an absolute need for it

in other words:

a.l = peekb(whatever) &$FF
writeb(a)

as you can see, i don't bother with a sign here, a long is certainly large enough to contain all values from 0 to 255

deadmoap · Post by **deadmoap** » Fri Aug 13, 2004 1:40 am

It's still using the same amount of numbers, but instead of 0 to 256, it's -128 to 128.

Froggerprogger · Post by **Froggerprogger** » Fri Aug 13, 2004 8:53 am

It's still using the same amount of numbers, but instead of 0 to 256, it's -128 to 128.

>>ZONK<<
....instead of 0 to 255 it's -128 to 127