Hacker News Reader

Comment by tmtvl | Hacker News Reader

Move to 128-bit time.

You laugh but a big danger with “too big” but representations is the temptation to use the “unused” bits as flags for other things.

We’ve seen it before with 32 bit processors limited to 20 or 24 bits addressable because the high order bits got repurposed because “nobody will need these”.

Doesn't the opposite happen with 64 bit pointers on x86_64? the lower bits have no use so they get used for tracking if a memory segment is in use or other stuff

Good article on the subject: https://mikeash.com/pyblog/friday-qa-2015-07-31-tagged-point...

And with 64-bit pointers in Linux, where you have to enable kernel flags to use anything higher than 48 bits of the address space. All because some very misguided people figured it would be ok to use those bits to store data. You'd think the fact that the processor itself will throw an exception if you use those bits would be a red flag of "don't do that", but you would apparently be wrong.

> You'd think the fact that the processor itself will throw an exception if you use those bits would be a red flag of "don't do that"

That makes it slightly safer to use those bits, won’t it? As long as your code asks the OS how many bits the hardware supports, and only use the ones it requires to be zero, if you forget to clear the bits before following a pointer, the worst that can happen is a segfault, not reading ‘random’ memory.

Best to switch to 512 bits, that's enough to last until the heat death of the universe, with plenty of margin for time dilation.

Maybe we can add a register to the processors for just keeping time. At the end of the day, it's a ticker, no?

RTX[0-7] would do. For time dilation purposes, we can have another 512 bit set to adjust ticking direction and frequency.

Or shall we go 1024 bits on both to increase resolution? I'd agree...

Best to switch to Smalltalk integers which are unlimited...

Just use LEB128.

Reply on news.ycombinator.com