Pointer variable type
Elsewhere I've recommended that, when writing portable code, pointers (memory addresses if you prefer) should be stored in suffixless variables, for example mem.
This is on the basis that whilst not all versions of BBC BASIC support 64-bit integers (e.g. mem%%) they are all capable of holding an arbitrary pointer in a suffixless variable.
This is certainly true of all 16-bit or 32-bit-address versions, because their suffixless variables are either 40-bit floats (64-bit in the case of ARM BASIC VI) or variants, any of which can contain an arbitrary 32-bit integer.
It is also true of my 64-bit-address versions (principally MacOS, Linux, Android and iOS) because their suffixless variants can contain arbitrary 64-bit integers, even when running on an ARM CPU.
But I just want to check that it's true of Matrix Brandy. I think it should be, because whilst Brandy's suffixless variables are 64-bit doubles, which cannot hold an arbitrary 64-bit integer, x86-64 pointers are limited to (signed) 48-bit integers which should fit.
Can you confirm that?
This is on the basis that whilst not all versions of BBC BASIC support 64-bit integers (e.g. mem%%) they are all capable of holding an arbitrary pointer in a suffixless variable.
This is certainly true of all 16-bit or 32-bit-address versions, because their suffixless variables are either 40-bit floats (64-bit in the case of ARM BASIC VI) or variants, any of which can contain an arbitrary 32-bit integer.
It is also true of my 64-bit-address versions (principally MacOS, Linux, Android and iOS) because their suffixless variants can contain arbitrary 64-bit integers, even when running on an ARM CPU.
But I just want to check that it's true of Matrix Brandy. I think it should be, because whilst Brandy's suffixless variables are 64-bit doubles, which cannot hold an arbitrary 64-bit integer, x86-64 pointers are limited to (signed) 48-bit integers which should fit.
Can you confirm that?
0
Comments
-
From my reading of the issue, no current or planned future x86_64 processor uses an address width greater than 52 bits, and this can be accurately represented in a double.
However, AArch64 supports up to 56 bit addresses.
https://developer.arm.com/documentation/101811/0104/Address-spaces/Size-of-virtual-addresses0 -
I suppose in principle that could affect Matrix Brandy if built for the 64-bit Raspberry Pi, but in practice I would be surprised if the PiOS memory manager ever assigns virtual addresses bigger than 52-bits, given the limited RAM of that machine.However, AArch64 supports up to 56 bit addresses.0 -
If my reading is correct (and it probably isn't), it defaults to 48 bits so I should be OK, and I would be surprised if an OS enabled more bits of it wasn't necessary.0
-
I think we're safe. A little Googling suggests that on both x86-64 and aarch64 architectures virtual addresses are normally limited to 48 bits (4K pages) and the maximum possible is 52 bits (needing a 64K page size), both of which fit in a double.If my reading is correct (and it probably isn't), it defaults to 48 bits so I should be OK, and I would be surprised if an OS enabled more bits of it wasn't necessary.
1 -
That's good to know! I've always shied away from using FP variables for pointers in BBC BASIC (any version), probably not helped because even back in the day integer variables were almost always used in examples I saw, even on the 8-bit kit.0
-
Probably for speed, but if you are wanting to write a program which is portable across the entire range of BBC BASIC interpreters, from the 6502 version through to modern 64-bit editions, the suffixless variable is your only choice for holding a pointer.back in the day integer variables were almost always used in examples I saw, even on the 8-bit kit.
Of course in my versions, including the original Z80 version, suffixless variables aren't floating point, they're variants, so there is no speed penalty involved in their use anyway.
In my recent Googling on the address width issue I came across LuaJIT, which plays similar tricks to my BASICs in using 'special' floating-point variables to hold different data types. In their case they are repurposing NaNs for this use (you can consider my 40-bit variants as being FP NaNs).
0