5 ms·

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, righ

by oobey 10y ago

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

kazinator 10y ago
More is always better. Four wheels is better than two; cars should have eight wheels. Look at GUID partition tables. With MBR, we had to hobble along with only a byte to identify partition types. Now we have 128 bits. We can finally support more filesystem kinds now than there are atoms in the Sun, all in one system installation, and the bootloader just has to look at the GUID. A 32 bit "fourcc" partition label clearly wouldn't have been enough.
- XorNot 10y ago
  GUID partition tables mean we don't need to coordinate identifiers. That's the point.
  - kazinator 10y ago
    But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence. A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap). If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab. The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.
    - XorNot 10y ago
      Why have them at all then? If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.
      - kazinator 10y ago
        Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.
        XorNot 10y ago
        So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk? Why not a nibble and just use the other 4 bits for flags? The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems. With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.
        kazinator 10y ago
        Indeed; one byte works for me. Four is a reasonable political compromise between "one byte works for me" and "oh my, what about clashes?" 16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month. The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not. > With GPT, if I want to make a new filesystem type for some application ... Four bytes could have an ample reserved range for local use by hobbyists. Broad recognition of the code only matters if the application is very widely deployed.
whitefish 10y ago
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.
- wolfgke 10y ago
  > 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.
- phkahler 10y ago
  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?
- floatboth 10y ago
  "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-on-twitter-in-2-hours/ https://techcrunch.com/2009/06/12/all-hell-may-break-loose-o...
loarabia 10y ago
I think he touched on this a little in a follow-up he did: https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/ https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis... My interpretation of the shift from < 32 bits into 32 bits is: before we had do do crazy things to algorithms we used to fit in those address spaces. When we transitioned to 32 bits, we didn't have to do that anymore. So the question might be are there any surprising workarounds in the code because you're only dealing with 32 bit code where if you had 64 bits you could write some more elegant solution.
- syncsynchalt 10y ago
  It's not exactly what you're asking for, but you'll run into a big one in about two decades. The only other example I can think of is the general "problem" of large databases. There's just a lot more paging and churn that has to happen in a 32-bit address space. Many NoSQL databases in particular have a memory model of mmap'ing an entire database, which runs into a hard limit on 32-bit address space.
deleted 10y ago
[deleted]
mschaef 10y ago
You could continue this argument out to 128 or 256 bits. Where it starts to fall down is when you map the size of those address spaces back to the data types people work with. In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Even a moderately sized text document will be bigger than 64K... and that's before considering images, videos, large data sets, etc. 32-bit takes you out to 4GB, which is much more likely to hold a typical working set, so the argument to go to 64-bit is much less pressing. "why not stick with 8 bit?" This conversation is about the size of the address space, not the machine word size. To my knowledge, there were no serious machines of any sort that were limited to an 8-bit address space. (Maybe something homebrew or embedded.) The closest I can think of is the 6502's preference for putting values in the zero page (which was 256 bytes).
- wolfgke 10y ago
  > In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Depends on the way 16 bit is implemented. For example x86-16 uses segmented memory - enabling adressing of a little bit more (including High Memory Area) than 1 MiB of memory. The Z180 uses as far as I know a MMU (but not completely sure). Another approach that is/was in common use is to use bank switching. Depending on the kind of algorithm that you use this can make the coding much more complicated or can also be no problem, because the scheme that is used to address more memory than 2^16 bytes fits the algorithm quite natural. One interesting hack for example when coding in real mode (x86-16) that I read about is rather to use some clever sharing of bits between the segment register value and segment index: - One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further) - Another scheme is to (mostly) use only the 4 highest bits of the segment register (and zero all the other ones).
  - mschaef 10y ago
    "One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)" This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.
pvg 10y ago
No, because the steps are exponential. You can sit down and type your way through 64k. If this was an argument by induction, then 1 bit would have been fine too.

by oobey 10y ago

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

kazinator 10y ago

More is always better. Four wheels is better than two; cars should have eight wheels. Look at GUID partition tables. With MBR, we had to hobble along with only a byte to identify partition types. Now we have 128 bits. We can finally support more filesystem kinds now than there are atoms in the Sun, all in one system installation, and the bootloader just has to look at the GUID. A 32 bit "fourcc" partition label clearly wouldn't have been enough.

XorNot 10y ago
GUID partition tables mean we don't need to coordinate identifiers. That's the point.
- kazinator 10y ago
  But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence. A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap). If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab. The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.
  - XorNot 10y ago
    Why have them at all then? If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.
    - kazinator 10y ago
      Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.
      - XorNot 10y ago
        So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk? Why not a nibble and just use the other 4 bits for flags? The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems. With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.
        kazinator 10y ago
        Indeed; one byte works for me. Four is a reasonable political compromise between "one byte works for me" and "oh my, what about clashes?" 16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month. The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not. > With GPT, if I want to make a new filesystem type for some application ... Four bytes could have an ample reserved range for local use by hobbyists. Broad recognition of the code only matters if the application is very widely deployed.

whitefish 10y ago

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.

wolfgke 10y ago
> 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.
phkahler 10y ago
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?
floatboth 10y ago
"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-on-twitter-in-2-hours/ https://techcrunch.com/2009/06/12/all-hell-may-break-loose-o...

loarabia 10y ago

I think he touched on this a little in a follow-up he did: https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/ https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis... My interpretation of the shift from < 32 bits into 32 bits is: before we had do do crazy things to algorithms we used to fit in those address spaces. When we transitioned to 32 bits, we didn't have to do that anymore. So the question might be are there any surprising workarounds in the code because you're only dealing with 32 bit code where if you had 64 bits you could write some more elegant solution.

syncsynchalt 10y ago
It's not exactly what you're asking for, but you'll run into a big one in about two decades. The only other example I can think of is the general "problem" of large databases. There's just a lot more paging and churn that has to happen in a 32-bit address space. Many NoSQL databases in particular have a memory model of mmap'ing an entire database, which runs into a hard limit on 32-bit address space.

deleted 10y ago

[deleted]

mschaef 10y ago

You could continue this argument out to 128 or 256 bits. Where it starts to fall down is when you map the size of those address spaces back to the data types people work with. In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Even a moderately sized text document will be bigger than 64K... and that's before considering images, videos, large data sets, etc. 32-bit takes you out to 4GB, which is much more likely to hold a typical working set, so the argument to go to 64-bit is much less pressing. "why not stick with 8 bit?" This conversation is about the size of the address space, not the machine word size. To my knowledge, there were no serious machines of any sort that were limited to an 8-bit address space. (Maybe something homebrew or embedded.) The closest I can think of is the 6502's preference for putting values in the zero page (which was 256 bytes).

wolfgke 10y ago
> In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Depends on the way 16 bit is implemented. For example x86-16 uses segmented memory - enabling adressing of a little bit more (including High Memory Area) than 1 MiB of memory. The Z180 uses as far as I know a MMU (but not completely sure). Another approach that is/was in common use is to use bank switching. Depending on the kind of algorithm that you use this can make the coding much more complicated or can also be no problem, because the scheme that is used to address more memory than 2^16 bytes fits the algorithm quite natural. One interesting hack for example when coding in real mode (x86-16) that I read about is rather to use some clever sharing of bits between the segment register value and segment index: - One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further) - Another scheme is to (mostly) use only the 4 highest bits of the segment register (and zero all the other ones).
- mschaef 10y ago
  "One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)" This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.

pvg 10y ago

No, because the steps are exponential. You can sit down and type your way through 64k. If this was an argument by induction, then 1 bit would have been fine too.