07-19-2023, 11:15 PM
(07-19-2023, 01:42 PM)SMcNeill Wrote: It's just another reason to keep in mind that it's all up to the OS for where/how it places your data in memory. I wouldn't trust that the space between is always going to be 8-bytes for anything. (Especially if mem usage starts to increase and the OS starts to reshuffle and pack program memory.)I haven't been following too closely, but I just wanted to point out that the OS does _not_ determine where your data is placed in memory. That is entirely up to the application and the OS will never move it. Most of those decisions are decided at compile time by the compiler, but memory allocations are decided at runtime by various things (QB64 runtime, C runtime, etc.).
Additionally, you should note that (for reasons) QB64 allocates local variables at runtime, that's why things are a bit different compared to other languages . Currently QB64 has a
mem_static_malloc()which is used to allocate local/stack variables, and it aligns all returned addresses to 8 bytes. Really I'd like to replace the whole thing, as that's not even the correct thing to do (
_FLOATneeds 16 byte alignment), but that's why all variables appear to take up at least 8 bytes - we ask
mem_static_malloc()to give us 1, 2, or 4 bytes, and it gives the lowest multiple of 8 that's higher or equal to what we asked for - in that case, 8.
None of that is documented because as far as the programmer cares, it doesn't matter. Even if
mem_static_malloc()reserves an 8-byte chunk of memory, the LONG value it's for is only going to use 4 of those bytes as it's a 4-byte integer - the size of the variable does not change and you'd never know unless you're manually comparing the addresses between variables. It wastes a minor amount of memory, but that's it. Additionally this only applies to locally declared variables. Arrays are allocated separately and won't have that 'extra' space in-between each array entry.