On Saturday, 20 July 2024 at 17:32:40 UTC, IchorDev wrote:

Use 64bit pointers anyway and translate them before handing it over to the system. How is memory above 4GB handled on such systems? The answer is: there is already a translation from process address space to hardware addresses. This need only a little adjustment.

Same of course.

Not a problem unless those bits are used for other purposes by the system.

?!?
Why? I mean, alignment maybe required also by other means, but that translate only to ignoring the lower bits and fiddling out the requested bits by shifts.

Of course all this is just a workaround unless processors exists that support bit addresses directly. But I see no reason why that should be problematic at all. The low address lines doesn't even need to exist. On 68000 there was also no line for odd addresses, so you needed to get 16bit and then shift if access to an odd byte was necessary. And it worked.

On Saturday, 20 July 2024 at 20:18:32 UTC, Dom DiSc wrote:

Which will take a whole extra register, defeating the point of trying to cram data into pointers. Just using a different register is a much better solution in general, it's just a bit wasteful. If you care so much waste though, you shouldn't be using a language with slices—in D they take 2 times more space than a pointer when you could just be using null-terminated arrays instead.

And this is done by the kernel, so I don't see how it's relevant to this conversation unless we are re-writing iOS' kernel?

So what you are proposing will not work for those systems.

Let's say we have a 64 bit pointer (U='unused'; P=pointer bits; X=zeroed bits ; C=our data):
UUUUUUUU UUUUUUUU PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP
Now we shift 3 bits to the right:
XXXUUUUU UUUUUUUU UUUPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP
We just lost the 3 least significant bits of the original pointer, so unless it was storing a multiple of 8 we just lost important data.
Now we will use the lower 3 bits to indicate the bit offset:
XXXUUUUU UUUUUUUU UUUPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPCCC
We just overwrote more of the existing pointer… so actually it would have to be aligned to a multiple of 64, or we just lost important data.
Also the kernel often uses these 'unused' bits in the pointer, so we would have to tread lightly, and also compiled code would have to know not just what OS it's targeting, but also what kernel version it's targeting in case of changes to this arrangement. In practice it's not as bad as it sounds, but it could be a frustrating headache to debug.

Lastly, in general bit-packing optimisations like this are terribly slow. It's probably just not worth the tiny memory gain.

On Sunday, 21 July 2024 at 06:14:05 UTC, IchorDev wrote:

No. This is a misunderstanding.
My idea is to store all pointers as "61bit address"+"3bit bitoffset (0..7 within a byte). No lower bits will be lost.
To read we give the system only the address (so p>>3) and then mask out the requested bit. Of course this address will contain 3 leading (unused) zeroes. As long as the system don't abuse these unused bits, everything is fine.
Also this is no "extra data". It's just adding the 3 missing address lines that are necessary to address single bits instead of blocks of 8 bits (yes, bytes are just a 8bit alignment, they shouldn't be fundamental - but as long as these 3 lines are missing, we need a workaround like in the 68000er times, where another line was missing). And yes, the workaround is time consuming - but really not that bad. And less bad if you require "even" types to be aligned to there size, as it is also required for bytes and shorts or even for ints on 64bit systems.

On Sunday, 21 July 2024 at 10:25:29 UTC, Dom DiSc wrote:

Multi-bit alignment (e.g. 8-bit) is a means of simplifying and therefore speeding up the CPU architecture. Having 3 lines for individual bits would be a huge waste of electricity. As it is, I think being able to address individual bytes is a bit antiquated, especially with new CPUs heavily favouring pointer-size alignment.

On Sunday, 21 July 2024 at 16:19:04 UTC, IchorDev wrote:

Vice Versa. The address space of 64bit is so huge, having extra lines for all the unused high bits is a waste of electricity. Using them to address individual bits enables us to write consistent, less complex code, e.g. no invalid patterns for basic types with gaps (e.g. boolean). And this code need not be slower - alignment and shifting can be optimized away in the background / hardware, the compiler can arrange variables to minimize gaps and speed up access by aligning.

On Sunday, 21 July 2024 at 16:19:04 UTC, IchorDev wrote:

x86 CPUs favour type alignment not pointer size alignment, bytes 1 align, shorts 2 align and so on.

It's mostly to avoid buggering up the store to load forwarding IIRC. Which is basically a way of making recent writes faster to retrieve when they are loaded again.

And as far as I know ARM is the same.

On Sunday, 21 July 2024 at 20:56:00 UTC, Dom DiSc wrote:

Neither x64 or Arm use all 64 bits, AFAIK they only use the bottom 48 bits, the upper 16 should be zeroed.