Integer memory storage

[SMcNeill]

Array of bits. I gather an array of 2-byte integers could be the same way, as long as the size is a multiple of 32. I don't know if code things still depend on a single data item being dropped directly into a CPU register. It should be, if not then why Freebasic's developers redefined ```INTEGER``` keyword as 64-bit integer? (shrugs)

I have learned that when declaring UDT's in a 16-bit system, things run "more efficiently" if the total byte size were a multiple of eight. So it had me declaring something like this as final element:

Code: (Select All)

FILLER AS STRING * 77

I don't know but today that looks foolish to me.

It often has to do with your OS and data packing/alignment.

On 32-bit OSes, data aligns on 4-byte intervals.  On 64-bit OSes, data aligns on 8-byte intervals.  The reason is simple -- that's how many bytes one register holds, so it's just grabbing your data and using it, rather than having to split it up into multiple reads.

For example:

TYPE Foo
     x AS INTEGER
     y AS LONG
     z AS STRING * 3
END TYPE

Now, on a 32-bit OS, it tends to store that data as:

 TYPE Foo
     x AS INTEGER
FILLER AS STRING * 2
     y AS LONG
     z AS STRING * 3
FILLER AS STRING *1
END TYPE

Now, with one read from memory, you can get the data for x, y, or z, by reading a 4-byte chunk of information and making use of the portion you want.

As it was previously, you'd have multiple reads to get your data. If you wanted info on y, you head to read 2 bytes with x, then 2 bytes with z, then add those bytes together to make y... And that's a lot more reading and assembling and processing and it's just a mess.

On 64-bit OS, that type tends to be aligned on 8-byte bounds such as:

TYPE Foo
     x AS INTEGER
     y AS LONG
FILLER AS STRING * 2
     z AS STRING * 3
FILLER AS STRING * 5
END TYPE

One pass to get the element in question, without any of that grab-a-chunk-here grab-a-chunk-there mess involved.

*****************************

Note: The reason why INTEGER is 2-bytes is because DOS -- which QB45 and BASIC was written for back in the day -- was a 16-bit operating system. FreeBasic devs decided they didn't need to try and keep backwards compatibility so much, as they wanted to move forward with modern features, so they apparently redefined INTEGER to be the size of what we'd consider a modern INTEGER to be on our systems -- 64-bit for most modern OSes.

QB64's goal has always been backwards compatibility as much as possible, so we still keep the INTEGER type as 2-bytes, just as QB45 did.