Epoch Fail (and other bitwise tales)
Today's xkcd cartoon, 2038 (regarding the y2038 time issue that looms on the horizon), prompts me to foam at the mouth about the annoyingly common misconception that a 64 bit CPU and OS are required to handle 64 bit time.
Curiously, I seem to recall handling numbers much larger than 256 on my 8-bit computers. Indeed, unixoid OS's have been handling 32 bit time just fine on 16 bit (and maybe even a few 8 bit) systems.
If the developers of 32 bit OS kernels are opting not to offer 64 bit time support (which i do not know to be true), it is by choice; it is not because it is impossible-or even merely impractical. It is possible, practical, and important; we're not yet done with 32 bit computing. (Heck! We're not even quite done with 16 or even 8 bit computing, in the embedded world.)
Meanwhile, a 64 bit CPU is required to directly addresse more than 4 GiB of RAM; but this is mainly a coincidence of design. The addresse busses of most 32 and 64 bit CPUs match the width of their data busses because it is convenient-not because it would be impossible to make a 32 bit CPU with a wider addresse bus. Over the years, we've seen plenty of CPUs with addresse busses wider than their data width. Most 8 bit CPUs (6502, 6800, Z80, 8080) have had 16 bit addresse busses. the most popular 16 bit CPUs have had 20 bit (8086, 8088), 24 bit (80286, 65816), or 32 bit (68000) addresse busses (though only 24 of the 68000's 32 addresse bits, are externally available).
The 4 GiB memory issue in 32 bit Windows (i.e. that it won't use that much RAM) is amusingly similar to the old 640 kiB issue from the 8086 days. The 8086 (and its externally 8 bit sibling, the 8088) has a 1 MiB addresse range. The reason that the IBM-PC and its kind suffered a 640 kiB limit is that the upper 384 kiB was reserved for firmware and video RAM. (This was somewhat mitigated with a bank switching scheme known as expanded memory (EMS).) Likewise, some of the addresse space of the typical 32 bit x86 box is used for firmware and other hardware related things-confiscating the better part of a GiB in most cases. (A similar story is also behind the 48 kiB RAM limit of an 8 bit Apple II before resorting to bank switching.)
Just as the 24 bit addresse bus of the 65816 sent the 64 k limit (and associated workarounds) of 6502 based computers 256-fold into the distance, so the 64 bit addresse busses of the typical 64 bit CPU, of course, casts the 4 gig limit of 32 bit addressing CPUs 4-billion-fold into the distance, where it shouldn't be a problem for at least another decade or so. ;)
[I probably should separate those last three paragraphs into their own article, to avoid cluttering up the initial subject of 64 versus 32 bit time. But there it is, in all it's glorious thought pile.]
Curiously, I seem to recall handling numbers much larger than 256 on my 8-bit computers. Indeed, unixoid OS's have been handling 32 bit time just fine on 16 bit (and maybe even a few 8 bit) systems.
If the developers of 32 bit OS kernels are opting not to offer 64 bit time support (which i do not know to be true), it is by choice; it is not because it is impossible-or even merely impractical. It is possible, practical, and important; we're not yet done with 32 bit computing. (Heck! We're not even quite done with 16 or even 8 bit computing, in the embedded world.)
Meanwhile, a 64 bit CPU is required to directly addresse more than 4 GiB of RAM; but this is mainly a coincidence of design. The addresse busses of most 32 and 64 bit CPUs match the width of their data busses because it is convenient-not because it would be impossible to make a 32 bit CPU with a wider addresse bus. Over the years, we've seen plenty of CPUs with addresse busses wider than their data width. Most 8 bit CPUs (6502, 6800, Z80, 8080) have had 16 bit addresse busses. the most popular 16 bit CPUs have had 20 bit (8086, 8088), 24 bit (80286, 65816), or 32 bit (68000) addresse busses (though only 24 of the 68000's 32 addresse bits, are externally available).
The 4 GiB memory issue in 32 bit Windows (i.e. that it won't use that much RAM) is amusingly similar to the old 640 kiB issue from the 8086 days. The 8086 (and its externally 8 bit sibling, the 8088) has a 1 MiB addresse range. The reason that the IBM-PC and its kind suffered a 640 kiB limit is that the upper 384 kiB was reserved for firmware and video RAM. (This was somewhat mitigated with a bank switching scheme known as expanded memory (EMS).) Likewise, some of the addresse space of the typical 32 bit x86 box is used for firmware and other hardware related things-confiscating the better part of a GiB in most cases. (A similar story is also behind the 48 kiB RAM limit of an 8 bit Apple II before resorting to bank switching.)
Just as the 24 bit addresse bus of the 65816 sent the 64 k limit (and associated workarounds) of 6502 based computers 256-fold into the distance, so the 64 bit addresse busses of the typical 64 bit CPU, of course, casts the 4 gig limit of 32 bit addressing CPUs 4-billion-fold into the distance, where it shouldn't be a problem for at least another decade or so. ;)
[I probably should separate those last three paragraphs into their own article, to avoid cluttering up the initial subject of 64 versus 32 bit time. But there it is, in all it's glorious thought pile.]