Re:Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
by whitefish on Friday March 10, 2017 @10:09AM
(#13839120)
No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit. This problem went away with 32 bit. Adding more bits beyond 32 does not bring proportional benefits because the numbers we deal with fit in 32 bit.
[ Parent
| on HN ]
Re:Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
by floatboth on Friday March 10, 2017 @12:29PM
(#13840263)
"the numbers we deal with fit in 32 bit"
Except when they don't. Everyone already forgot tweet number 2147483648? :) https://techcrunch.com/2009/06/12/all-hell-may-break-loose-o...
Re:Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
by wolfgke on Friday March 10, 2017 @10:24AM
(#13839237)
> No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit.
Wrong (for x86-16 vs. x86-32). Just use an operand-size size override prefix (0x66) with your 16 bit real mode ALU (in this case 'add') instruction to make it a 32 bit ALU instruction. Works from 80386 on, where the 32 bit registers were introduced.
Re:Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)
by phkahler on Friday March 10, 2017 @10:31AM
(#13839309)
I agree, most numbers we deal with fit in 32 bits with the exception of double precision floating point and indexes for really large data sets. As Moore's law seems to be ending perhaps there might be a sweet spot at 48bits for both integer and FP.
The one thing I found absurd with RISC-V is the 128bit variant. Most 64bit processors today don't even support a full 64bit virtual address space do they?