+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Utilities (https://qb64phoenix.com/forum/forumdisplay.php?fid=8)
+---- Thread: Sample program using the new _Files$ function (/showthread.php?tid=2393)
RE: Sample program using the new _Files$ function - eoredson - 02-06-2024
@steve: Thanks for the intel!
It seems a Byte would be, of course, a byte, where a signed byte holds 0 to 127 and an unsigned byte would hold 0 to 255 and
an integer would contain 2 bytes.. Obviously there is no bit or nibble. It does not answer my question why you could assign a _bit in the first place.
RE: Sample program using the new _Files$ function - SMcNeill - 02-06-2024
(02-05-2024, 04:00 PM)NakedApe Wrote: So, Steve, I've been using _BYTEs for my boolean TRUE/FALSE flags thinking that they take up less memory than an INTEGER. Is that a FALSE notion?
_BYTES are good. Bytes are your friend, as they're only 1 byte in size. (That's as small a chunk of data as you can store on your drive, or in memory.)
INTEGERs are 2 bytes in size, so you'd use twice as many bytes to just hold a simple True or False value.
The issue is there's folks who somehow think _BIT is better than _BYTE, and it's not. _BIT only has one use -- and I'd call it a very limited case use scenario -- and that's for bit packing arrays.
DIM Array(800) AS _BIT
The above would pack 800 bits into that array and store them in 100 bytes. Your program would use less memory and the data would take up less space on disk.
The disadvantage? It's a lot like compressing files into a zip or 7z archive. Sure, those files are smaller, but they're useless until you extract them. To make use of them, you've got to load them, decompress them, then reference them.
And that's basically how bit packing works. Packing 800 bits of data into 100 bytes, which then has to be extracted, "mathed upon" to get the right bit value from the relevant byte, and then used in your program.
It's a lot of overhead in a program, and for what?? In this case, you'd save 700 bytes of memory/storage? WOOOOOOOOOOOOOOOOooooooooo....
Without *LARGE* Arrays for bitpacking, there's just not much use for the variable type. Definitely no use for it when it comes to storing single values, which you then compress/decompress, just to end up storing in a byte anyway.
(02-05-2024, 04:16 PM)SpriggsySpriggs Wrote: I think integers and bytes are the same size on the backend, if I'm not mistaken.
INTEGERS are 2 bytes. _BYTE is 1 byte.
Code: (Select All)
Dim b As _Byte
Dim i As Integer
Print Len(b)
Print Len(i)
RE: Sample program using the new _Files$ function - SMcNeill - 02-06-2024
(02-06-2024, 12:31 AM)eoredson Wrote: @steve: Thanks for the intel!
It seems a Byte would be, of course, a byte, where a signed byte holds 0 to 127 and an unsigned byte would hold 0 to 255 and
an integer would contain 2 bytes.. Obviously there is no bit or nibble. It does not answer my question why you could assign a _bit in the first place.
A byte is a byte. An integer is 2 bytes.
A bit is just a portion of a byte.
Thing is, think of it like taking a pie and cutting it into 8 slices. You eat 7 slices, only leaving one behind.... Now, when you put that pie back in the fridge, how much space does that 1/8th take up compared to the whole pie??
It takes up the same dang amount of space!! That slice of pie is still in the same pie pan! It's just got 7 slices which are still missing, but the pan it's stored in is the same as always!
That's what a single bit does -- it still takes up that one space inside a byte.
The *only* time it's useful is when you're bit packing. To think of it in terms of pies, let's say you have:
1 slice of chocolate pie.
1 slice of lemon pie.
2 slices of custard pie.
3 slices of apple pie.
1 slice of cherry pie.
Now, if each of those pies are in their own pie pan, that's going to take up space for 5 pies in your fridge. Now, if you take all those pieces, arrange them together into one pie pan, you can pack them all together and save some space.
That's basically bit-packing. Taking multiple bits and storing them in the same byte. Unfortunately, the only way to do that is to say, "This is a VARIETY PLATTER of pies." You can't store them as individual pies anymore and call them "Chocolate Pie", "Lemon Pie", "Custard Pie"....
You'd basically have to DIM Variety_Platter(1 TO 8) AS _BIT. You couldn't DIM Choco AS _Bit, Lemon AS _Bit, Custard AS _Bit...
Array bit packing is the only time you should ever consider using bits. Otherwise, just use bytes. (And only consider it for LARGE bit arrys, as otherwise the overhead just isn;t going to be worth it on modern systems. I've got 128GB of Ram. Why should I care if I use 3MB for a byte array, rather than 1/8th that amoung for a packed bit array??)
RE: Sample program using the new _Files$ function - eoredson - 02-07-2024
I was not trying to optimize Ram .. Just wondering why you could:
Code: (Select All)
Dim b As _bit * 32
b = &b1111
Print bCode: (Select All)
Type S
b As _bit * 32
End TypePatch in this code and try it:
Code: (Select All)
Type s
b As _Bit * 32
End Type
Dim z As s
Print z.bRE: Sample program using the new _Files$ function - SMcNeill - 02-07-2024
One is a variable. The other is an User Defined Type.
You can Dim b as _bit * 12, and this is going to be very easy to understand and process. You need 2 bytes to hold those 12 bits, so you store it as an INTEGER, and then AND &B111111111111 the value to make certain that you're only keeping 12 bits out of the total 16. (Or you shift left 4 times and then shift back right 4 times, for the same type reslt.)
But with a UDT, you have to account for other possibilites such as:
TYPE foo
b as _BIT
c AS _BIT
d as _BYTE
e as _BIT
f AS _FLOAT
END TYPE
Now, the argument suddenly explodes. What size should that data type be?
Should the compiler somehow optomize those 3 bits so they all take up the same byte?
Should the first two bits belong in the same byte, while the 3rd bit should be in a byte by itself?
Should all those bits be stored in individual bytes?
Heck, maybe there should be an option to specify how the user expects them to be!!
TYPE foo
b as _PACKED _BIT 1 OF _BYTE 1
c AS _PACKED _BIT 2 OF _BYTE 1
d as _BYTE
e as PACKED _BIT 3 OF _BYTE 1
f AS _FLOAT
END TYPE
Golly, wouldn't that be nice!
Well..... I guess it could be... But the overhead in processing such a thing.... And you're now checking *EVERY* UDT to see if this extended syntax applies to it... And you're packing data, and unpacking data, and tracking data positions, and OH MY GAWD!! Just what the BLEEP did you just do??? This certainly isn't BASIC anymore!! AHHHHHHH!!!!
See the simple difference in the two?
RE: Sample program using the new _Files$ function - eoredson - 02-07-2024
(02-07-2024, 05:38 AM)SMcNeill Wrote: One is a variable. The other is an User Defined Type.
You can Dim b as _bit * 12, and this is going to be very easy to understand and process. You need 2 bytes to hold those 12 bits, so you store it as an INTEGER, and then AND &B111111111111 the value to make certain that you're only keeping 12 bits out of the total 16. (Or you shift left 4 times and then shift back right 4 times, for the same type reslt.)
But with a UDT, you have to account for other possibilites such as:
TYPE foo
b as _BIT
c AS _BIT
d as _BYTE
e as _BIT
f AS _FLOAT
END TYPE
Now, the argument suddenly explodes. What size should that data type be?
Should the compiler somehow optomize those 3 bits so they all take up the same byte?
Should the first two bits belong in the same byte, while the 3rd bit should be in a byte by itself?
Should all those bits be stored in individual bytes?
Heck, maybe there should be an option to specify how the user expects them to be!!
TYPE foo
b as _PACKED _BIT 1 OF _BYTE 1
c AS _PACKED _BIT 2 OF _BYTE 1
d as _BYTE
e as PACKED _BIT 3 OF _BYTE 1
f AS _FLOAT
END TYPE
Golly, wouldn't that be nice!
Well..... I guess it could be... But the overhead in processing such a thing.... And you're now checking *EVERY* UDT to see if this extended syntax applies to it... And you're packing data, and unpacking data, and tracking data positions, and OH MY GAWD!! Just what the BLEEP did you just do??? This certainly isn't BASIC anymore!! AHHHHHHH!!!!
See the simple difference in the two?
Yes! Thank you for your wordy analogies.
Could the compiler fudge the UDT _Bit variable and internally process it as a _Byte and then syntax check it for 0/1 or 0/-1 and be done with it??
There has to be a way...
Erik.
I think this is the final post I want to do for this thread...
btw: you can't:
Code: (Select All)
n = 4
Dim x As _bit * n
Dim x As _bit * 2 * 2RE: Sample program using the new _Files$ function - SMcNeill - 02-07-2024
There's a VERY easy fix:
RE: Sample program using the new _Files$ function - SMcNeill - 02-07-2024
Maybe this will help -- I give you the ALL-POWERFUL Function Byte2Bit!!
Code: (Select All)
Dim b As _Byte
b = &B11
'but we only want a single bit!
b = Byte2Bit(b)
Print b
Function Byte2Bit~&& (a_byte As _Byte)
Byte2Bit = a_byte And 1~`1
End Function
RE: Sample program using the new _Files$ function - eoredson - 02-07-2024
Cool! Why bother with a bit when you could get a byte..
RE: Sample program using the new _Files$ function - eoredson - 02-14-2024
At least these still work:
Code: (Select All)
Dim b As _Unsigned _Bit * 4
b = &B1111
Print b
b = &HF
Print b
Dim s As _Unsigned _Byte
s = &B11111111
Print s
s = &HFF
Print sWhat if someone added a variable type of _Nybble
that is half of a byte??