61–70 of 359 posts
36 bit addresses would be better than 32, but I like being able to store a 64 bit double or pointer or integer in a word using NaN tagging (subject to the limitation that only 48 bits of the pointer are significant).
Funny thing is we sort-of got 36bit addressing mainstream with PAE in the 32bit x86 age.
Earlier quoted context omitted.
> simply don't because they are lazy and IPv4 works for them Or because IPv6 was not a simple "add more bits to address" but a much larger in-places-unwanted change.
Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT6…
Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
At the end: "Thank you to GPT 4o and o4 for discussions, research, and drafting." At first I thought that was a nice way to handle credit, but on further thought I wonder if this is necessary because the base line assumption is that everyone is using LLMs to help them write.
Problem is, not only did we have decades of C code that unnecessarily assumed 8/16/32, this all-the-world-is-a-VAX view is now baked into newer languages. C is good for portability to this kind of machine. You can have a 36 bit int (for instance), CHAR_BIT is defined as 9 and so on. With a little bit of extra reasoning, you can make the code fit different machines sizes so that you use all the available bits.
was that assumption in C code really unnecessary? i suppose it made many things much easier.
Sometimes the latter is a win, but not if that is your default modus operandi.
Another issue is that machine-specific code that assumes compiler and machine characteristics often has outright undefined behavior, not making distinctions between "this type is guaranteed to be 32 bits" and "this type is guaranteed to wrap around to a negative value" or "if we shift this value 32 bits or more, we get zero so we are okay" and such.
There are programmers who are not stupid like this, but those are the ones who will tend to reach for portable coding.
Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a…
At the end: "Thank you to GPT 4o and o4 for discussions, research, and drafting." At first I thought that was a nice way to handle credit, but on further thought I wonder if this is necessary because the base line assumption is that everyone is using LLMs to help them write.
Yeah, I don't remember ever thanking the spellchecker anything in the past. Maybe we are kinder to technology nowadays that we even credit it? Thank you to Android for mobile Internet connectivity, browsing, and typing.
Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a…
We just need 3 valued electronics