11 ms·

Possible reasons for 8-bit bytes

197 points by cpach 4y ago

billpg 4y ago
This was three or four jobs ago, but I remember reviewing someone's C code and they kept different collections of char* and int* pointers where they could have used a single collection of void* and the handler code would have been a lot simpler. The justification was that on this particular platform, char* pointers were differently structured to int* pointers, because char* pointers had to reference a single byte and int* pointers didn't. EDIT - I appear to have cut this story short. See my response to "wyldfire" for the rest. Sorry for causing confusion.
- wyldfire 4y ago
  > because char* pointers had to reference a single byte and int* pointers didn't. I must be missing some context or you have a typo. Probably most architectures I've ever worked with had `int *` refer to a register/word-sized value, and I've not yet worked with an architecture that had single-byte registers. Decades ago I worked on a codebase that used void * everywhere and rampant casting of pointer types to and fro. It was a total nightmare - the compiler was completely out of the loop and runtime was the only place to find your bugs.
  - billpg 4y ago
    I forget the details (long time ago) but char* and int* pointers had a different internal structure. The assembly generated by the compiler when code accessed a char* pointer was optimized for accessing single bytes and was very different to the code generated for an int* pointer. Digging deeper, this particular microcontroller was tuned for accessing 32 bits at a time. Accessing individual bytes needed extra bit-shuffling code to be added by the compiler.
    - leeter 4y ago
      Sounds like M68K or something similar, although Alpha AXP had similar byte level access issues. A compiler on either of those platforms likely would add a lot of fix up code to deal with the fact they have to load the aligned (either 16bit in M68K case or 32Bit IIRC in Alpha) and then do bitwise and shifts depending on the pointers lower bits. Raymond's blog on the Alpha https://devblogs.microsoft.com/oldnewthing/20170816-00/?p=96825 https://devblogs.microsoft.com/oldnewthing/20170816-00/?p=96...
      - monocasa 4y ago
        M68k was byte addressable just fine. Early alpha had that issue though, as did later cray compilers. Alpha fixed it with BWX (byte word extension). Early cray compilers simply defined char as being 64bits, but later added support for the shift/mask/thick pointer scheme to pack 8 chars in a word.
        leeter 4y ago
        Must have depended on variant, the one we used in college would throw a GP fault for misaligned access. It literally didn't have an A0 line. That said it's been over 10 years and I could be remembering the very hard instruction alignment rules as applying to data too...
        monocasa 4y ago
        16bits had to be aligned. It didn't have an A0 because of the 16bit pathway, but it did have byte select lines (#UDS, #LDS) for when you'd move.b d0,ADDR so that devices external to the CPU could see an 8-bit data access if that's what you were doing.
    - wyldfire 4y ago
      > char* and int* pointers had a different internal structure. The assembly generated by the compiler when code accessed a char* pointer was optimized for accessing single bytes and was very different to the code generated for an int* pointer. But -- they are different. Architectures where they're treated the same are probably the exception. Depending on what you mean by "very different" - most architectures will emit different code for byte access versus word access.
      - billpg 4y ago
        Accessing a 32 bit word was a simple read op. Accessing an 8 bit byte from a pointer, the compiler would insert assembly code into the generated object code. The "normal" part of the pointer would be read, loading four characters into a 32 bit register. Two extra bits were squirreled away somewhere in the pointer and these would feed into a shift instruction so the requested byte would appear in the lowest-significant 8 bits of the register. Finally, an AND instruction would clear the top 24 bits.
  - mlyle 4y ago
    There are architectures where all you have is word addressing to memory. If you want to get a specific byte out, you need to retrieve it and shift/mask yourself. In turn, a pointer to a byte is a software construct rather than something there's actual direct architectural support for.
    - loeg 4y ago
      Do C compilers for those platforms transparently implement this for your char pointers as GP suggests? I would expect that you would need to do it manually and that native C pointers would only address the same words as the machine itself.
      - mlyle 4y ago
        > Do C compilers for those platforms transparently implement this for your char pointers as GP suggests? Yes. Lots of little microcontrollers and older big machines have this "feature" and C compilers fix it for you. There are nightmarish microcontrollers with Harvard architectures and standards-compliant C compilers that fix this up all behind the scenes for you. E.g. the 8051 is ubiquitous, and it has a Harvard architecture: there are separate buses/instructions to access program memory and normal data memory. The program memory is only word addressable, and the data memory is byte addressable. So, a "pointer" in many C environments for 8051 says what bus the data is on and stashes in other bits what the byte address is, if applicable. And dereferencing the pointer involves a whole lot of conditional operations. Then there's things like the PDP-10, where there's hardware support for doing fancy things with byte pointers, but the pointers still have a different format than word pointers (e.g. they stash the byte offset in the high bits, not the low bits). The C standards makes relatively few demands upon pointers so that you can do interesting things if necessary for an architecture.
      - billpg 4y ago
        Depends on how helpful the compiler is. This particular compiler had an option to switch off adding in bit shifting code when reading characters and instead set CHAR_BIT to 32, meaning strings would have each character taking up 32 bits of space. (So many zero bits, but already handles emojis.)
  - kjs3 4y ago
    an architecture that had single-byte registers Wild guess, but the OP might be talking about the Intel 8051. Single-byte registers, and depending on the C compiler (and there are a few of them) 8-bit int* pointing to the first 128/256 bytes of memory, but up to 64K of (much slower) memory is supported in different memory spaces with different instructions and a 16-bit register called DPTR (and some implementations have 2 DPTR registers). C support for these additional spaces is mostly via compiler extensions analogous but different from the old 8086 NEAR and FAR pointers. I'm obviously greatly simplifying and leaving out a ton of details. Oh, yeah...on 8051 you need to support bit addressing as well, at least for the 16 bytes from 20h to 2Fh. It's an odd chip.
- dahart 4y ago
  It is true that on at least some platforms an int* that is 4 byte aligned is faster to access than a pointer that is not aligned. I don’t know if there are platforms where int* is assumed to be 4-byte aligned, or if the C standard allows or disallows that, but it seems plausible that some compiler somewhere defaulted to assuming an int* is aligned. Some compilers might generate 2 load instructions for an unaligned load, which incurs extra latency even if your data is already in the cache line. These days usually you might use some kind of alignment directive to enforce these things, which works on any pointer type, but it does seem possible that the person’s code you reviewed wasn’t incorrect to assume there’s a difference between those pointer types, even if there was a better option.
- hoseja 4y ago
  In C++, char* pointers are special in that they are exempt from aliasing rules.
ant6n 4y ago
Maybe another vague reason: when PCs came about in the era of the 8008...8086s, 64K of RAM was like a high, reasonable amount. So you need 16-bit pointers, which require exactly 2 bytes.
kleton 4y ago
ML might benefit a lot from 10bit bytes. Accelerators have a separate memory space from the CPU after all, and have their own hbm dram as close as possible to the dies. In exchange, you could get decent exponent size on a float10 that might not kill your gradients when training a model
- londons_explore 4y ago
  There seems to be as-yet no consensus on the best math primitives for ML. People have invented new ones for ML (eg the Brain Float16), but even then some people have demonstrated training on int8 or even int4. There isn't even consensus on how to map the state space onto the numberline - is linear (as in ints) or exponential (as in floats) better? Perhaps some entirely new mapping? And obviously there could be different optimal numbersystems for different ML applications or different phases of training or inference.
cwoolfe 4y ago
Because humans have 10 fingers and 8 is the closest power-of-two to that.
- gtop3 4y ago
  The article points out that a power of two bit count is actually less important than many of us assume at first.
gumby 4y ago
Author doesn't mention that several of those machines with 36-bit words had byte instructions allowing you to point at particular byte (your choice as to width, from 1-36 bits wide) and/or to stride through memory byte by byte (so an array of 3-bit fields was as easy to manipulate as any other size). Also the ones I used to program (PDP-6/10/20) had an 18-bit address space, which you may note is a CONS cell. In fact the PDP-6 (first installed in 1964) was designed with LISP in mind and several of its common instructions were LISP primitives (like CAR and CDR).
- drfuchs 4y ago
  Even more so, 6-bit characters were often used (supporting upper case only), in order to squeeze six characters into a word. Great for filenames and user id's. And for text files, 7-bit was enough to get upper and lower case and all the symbols, and you could pack five characters into a word. What could be better?
  - deleted 4y ago
    [deleted]
IIAOPSW 4y ago
Binary coded decimal makes perfect sense if you're going to output the value to a succession of 7 segment displays (such as in a calculator). You would have to do that conversion in hardware anyway. A single repeated circuit mapping 4 bits to 7 segments gets you the rest of the way to readable output. Now that I think about it, its surprising ASCII wasn't designed around ease of translation to segmented display.
- bregma 4y ago
  Maybe because ASCII is from the early 1960s and 7-segment displays didn't become widespread until 15 years or so later.
- kibwen 4y ago
  > Now that I think about it, its surprising ASCII wasn't designed around ease of translation to segmented display. Wikipedia has a section on the design considerations of ASCII: https://en.wikipedia.org/wiki/ASCII#Design_considerations https://en.wikipedia.org/wiki/ASCII#Design_considerations
  - jodrellblank 4y ago
    I love that there's a fractal world down there; from that the digits 0-9 start with bit pattern 0011 and then their value in binary to make easy convertion to/from BCD, and that control codes Start Message and End Message were positioned to maximise the Hamming distance so they're maximally different and least likely to be misinterpreted as each other in case of bits being mixed up, that 7-bit ASCII used on 8-bit tape drives left room for a parity bit for each character, that lowercase and uppercase letters differ only by the toggling of a single bit, that some of the digit/shift-symbol pairings date back to the first typewriter with a shift key in 1878...
    - jasomill 4y ago
      And my personal favorite: DEL is 1111111 so it could be punched over any other character to "delete" it from a paper tape.
908B64B197 4y ago
> (“a word is the natural unit of data used by a particular processor design”) Apparently on x86 the word size is 16 bits, even though the registers are 64 bits. That's true for the the original x86 instruction set. IA-32 has 32 bit word size and x86-64 has... you guessed it 64. 16 and 32 bit registers are still retained for compatibility reasons (just look at the instruction set!).
- loeg 4y ago
  Some x86 categorizations would call those dwords and qwords respectively.
- stefan_ 4y ago
  It's extra fun because not only are the registers retained, they were only extended. So you can use their 16 and 32 bit names to refer to smaller sized parts of them.
- tom_ 4y ago
  Words aeem to be always 16 bits for the x86 and derivatives - see the data types section of the software developer manual.
  - dragonwriter 4y ago
    I think "word" as a datatype evolved from its original and more general computing meaning of "the natural unit of data used by a processor design" (the thing we talk about with an "x-bit processor") to "16 bits" during the period of 16-bit dominance and the explosion of computing that was happening around it. Essentially, enough stuff got written assume=ing that "word" was 16 bits (and double word, quad word, etc., had their obvious relationship) that even though the term had not previously been fixed, it would break the world to let it change, even as processors with larger word sizes (in the "natural unit of data" sense) became available, then popular, then dominant.
moremetadata 4y ago
> why was BCD popular? https://www.truenorthfloatingpoint.com/problem https://www.truenorthfloatingpoint.com/problem Floating point arithmetic has its problems. [1] Ariane 5 ROCKET, Flight 501 [2] Vancouver Stock Exchange [3] PATRIOT MISSILE FAILURE [4] The sinking of the Sleipner A offshore platform [1] https://en.wikipedia.org/wiki/Ariane_flight_V88 https://en.wikipedia.org/wiki/Ariane_flight_V88 [2] https://en.wikipedia.org https://en.wikipedia.org /wiki/Vancouver_Stock_Exchange#Rounding_errors_on_its_Index_price [3] https://www-users.cse.umn.edu/~arnold/disasters/patriot.html https://www-users.cse.umn.edu/~arnold/disasters/patriot.html [4] https://en.wikipedia.org/wiki/Sleipner_A#Collapse https://en.wikipedia.org/wiki/Sleipner_A#Collapse
- elpocko 4y ago
  Can you elaborate? How/why is BCD a better alternative to floating point arithmetic?
  - finnh 4y ago
    floating point error. BCD guarantees you that 1/10th, 1/100th, 1/100th, etc (to some configurable level) will be perfectly accurate, without accumulating error during repeat calculations. floating point cannot do that, its precision is based on powers of 2 (1/2, 1/4, 1/8, and so on). For small values (in the range 0-1), there are _so many_ values represented that the powers of 2 map pretty tightly to the powers of 10. But as you repeat calculations, or get into larger values (say, in the range 1,000,000 - 1,000,001), the floating points become more sparse and errors crop up even easier. For example, using 32 bit floating point values, each consecutive floating point in the range 1,000,000 - 1,000,001 is 0.0625 away from the next. jshell> Math.ulp((float)1_000_000) $5 ==> 0.0625
    - elpocko 4y ago
      You can have infinite precision in pretty much any accurate representation though, no? Where is the advantage in using BCD over any other fixed point representation?
    - 4y ago
kibwen 4y ago
The reason to have a distinction between bits and bytes in the first place is so that you can have a unit of addressing that is different from the smallest unit of information. But what would we lose if we just got rid of the notion of bytes and just let every bit be addressable? To start, we'd still be able to fit the entire address space into a 64-bit pointer. The maximum address space would merely be reduced from 16 exabytes to 2 exabytes. I presume there's some efficiency reason why we can't address bits in the first place. How much does that still apply? I admit, I'd just rather live in a world where I don't have to think about alignment or padding ever again. :P
- ElevenLathe 4y ago
  64 bits of addressing is actually much more than most (any?) actually-existing processors have, for the simple reason that there is little demand for processors that can address 16 exabytes of memory and all those address lines still cost money.
  - FullyFunctional 4y ago
    More to the point, storing the pointers cost memory. Switching from 32-bit to 64-bit effectively halved the caches for pointer-rich programs. AMD64 was a win largely due to all the things they did to compensate (including doubling the number of registers).
- beecafe 4y ago
  [dead]
- jecel 4y ago
  The TMS340 family used bit addresses, but pointers were 32 bits. https://en.wikipedia.org/wiki/TMS34010 https://en.wikipedia.org/wiki/TMS34010
- cpleppert 4y ago
  There are a couple of efficiency reason besides the simple fact that every piece of hardware in existence operates on data sizes in powers of the byte. To start off with it would be fantastically inefficient to build a cpu that could load arbitrary bit locations so you would either be restricted to loading memory locations that are some reasonable fraction of the internal cache line or pay a massive performance penalty to load a bit address. Realistically what would you gain by doing this when the cpu would have to divide any location by eight (or some other fraction) to figure out which cache line it needs to load? The article touches on this but having your addressable unit fit a single character is incredibly convenient. If you are manipulating text you will never worry about single bits in isolation. Ditto for mathematical operations, do you really have a need for numbers less than 255? It is a lot more convenient to think about memory locations as some reasonable unit that covers 99% of your computing use cases.
samtho 4y ago
I’m kind of disappointed that embedded computing was not mentioned. It is the longest running use-case for resource constrained applications and there are cases where not only are you using 8-bit bytes but also an 8 bit CPU. BCD is still widely used in this case to encode data to 7 segment displays or just as data is relayed over the wire between chips.
- williamDafoe 4y ago
  I agree completely! See my answer up above. Only 7 or 8 bits makes sense for a microprocessor, not useful if you cannot store 0-100 in a byte! With ASCII(1963) becoming ubiquitous, the 8008 had to be 8-bits! Otherwise it would have been the 7007 lol ...
williamDafoe 4y ago
I worked on the UIUC PLATO system in the 1970s : CDC-6600, 7600 cpus with 60-bit words. Back then everything used magnetic core memory and that memory was unbelievably expensive! Sewn together by women in southeast Asia, maybe $1 per word! Having 6-bit bytes on a CDC was a terrific PITA! The byte size was a tradeoffs between saving MONEY (RAM) and the hassle of shift codes (070) used to get uppercase letters and rare symbols! Once semiconductor memory began to be available (2M words of 'ECS' - "extended core storage" - actually semiconductor memory - was added to our 1M byte memory in ~1978) computer architects could afford to burn the extra 2 bits in every word to make programming easier... At about the same time microprocessors like the 8008 were starting to take off (1975). If the basic instruction could not support a 0-100 value it would be virtually useless! There was only 1 microprocessor that DID NOT use the 8-bit byte and that was the 12-bit intersil 6100 which copied the pdp-8 instruction set! Also the invention of double precision floating point made 32-bit floating point okay. From the 40s till the 70s the most critical decision in computer architecture was the size of the floating point word: 36, 48, 52, 60 bits ... But 32 is clearly inadequate. But the idea that you could have a second larger floating point fpu that handled 32 AND 64-bit words made 32-bit floating point acceptable.. Also in the early 1970s text processing took off, partly from the invention of ASCII (1963), partly from 8-bit microprocessors, partly from a little known OS whose fundamental idea was that characters should be the only unit of I/O (Unix -father of Linux). So why do we have 8-bit bytes? Thank you, Gordon Moore!
- kjs3 4y ago
  I worked on the later CDC Cyber 170/180 machines, and yeah there was a C compiler (2, in fact). 60-bit words, 18-bit addresses and index registers, and the choice of 5-bit or 12-bit chars. The highly extended CDC Pascal dialect papered over more of this weirdness and was much less torturous to use. The Algol compiler was interesting as well. The 180 introduced a somewhat less wild, certainly more C friendly, 64-bit arch revision. There was only 1 microprocessor that DID NOT use the 8-bit byte Toshiba had a 12-bit single chip processor at one time I'm pretty sure you could make a similar claim about. More of a microcontroller for automotive that general purpose processor, tho.
- Taniwha 4y ago
PeterWhittaker 4y ago
Or maybe it was C? http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/#_36_bit_machines_and_the_persistence_of_octal http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/...
- cpleppert 4y ago
  The transition started before C, EBCDIC was 8 bits and ASCII was essentially a byte encoding. Unless you were designing some exotic hardware you probably needed to handle text and that was an eight bit byte. One motivation for the C type system was to extend the B programming language to support ASCII characters.
AdamH12113 4y ago
For those who are confused about bytes vs. words: The formal definition of a byte is that it's the smallest addressable unit of memory. Think of a memory as a linear string of bits. A memory address points to a specific group of bits (say, 8 of them). If you add 1 to the address, the new address points to the group of bits immediately after the first group. The size of those bit groups is 1 byte. In modern usage, "byte" has come to mean "a group of 8 bits", even in situations where there is no memory addressing. This is due to the overwhelming dominance of systems with 8-bit bytes. Another term for a group of 8 bits is "octet", which is used in e.g. the TCP standard. Words are a bit fuzzier. One way to think of a word is that it's the largest number of bits acted on in a single operation without any special handling. The word size is typically the size of a CPU register or memory bus. x86 is a little weird with its register addressing, but if you look at an ARM Cortex-M you will see that its general-purpose CPU registers are 32 bits wide. There are instructions for working on smaller or larger units of data, but if you just do a generic MOV, LDR (load), or ADD instruction, you will act on 32 register bits. This is what it means for 32 bits to be the "natural" unit of data. So we say that an ARM Cortex-M is a 32-bit CPU, even though there are a few instructions that modify 64 bits (two registers) at once. Some of the fuzziness in the definition comes from the fact that the sizes of the CPU registers, address space, and physical address bus can all be different. The original AMD64 CPUs had 64-bit registers, implemented a 48-bit address space, and brought out 40 address lines. x86-64 CPUs now have 256-bit SIMD instructions. "32-bit" and "64-bit" were also used as marketing terms, with the definitions stretched accordingly. What it comes down to is that "word" is a very old term that is no longer quite as useful for describing CPUs. But memories also have word sizes, and here there is a concrete definition. The word size of a memory is the number of bits you can read or write at once -- that is, the number of data lines brought out from the memory IC. (Note that a memory "word" is technically also a "byte" from the memory's point of view -- it's both the natural unit of data and the smallest addressable unit of data. CPU bytes are split out from the memory word by the memory bus or the CPU itself. Since computers are all about running software, we take the CPU's perspective when talking about byte size.)
- fanf2 4y ago
  In the Microsoft world, “word” generally means 16 bits, because their usage dates back to the 16 bit era. Other sizes are double words and quad words In the ARM ARM, a word is 32 bits, because that was the Arm’s original word size. Other sizes are half words and double words. It is a very context-sensitive term.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
sargstuff 4y ago
~60's computing grew out of the field of telecommunications [0][1]. When ASCII was released in 1963[3], integrated circuits didn't exist. Computing hardware was a build it from available, off the shelf parts endeavor. Easy to repurpose readily available 4-wire[2] to operate 4 wire relay. (2 relays -> 8 bits). ----- [0] http://ed-thelen.org/comp-hist/Reckoners-ch-4.html http://ed-thelen.org/comp-hist/Reckoners-ch-4.html [1] http://quadibloc.com/comp/cardint.htm http://quadibloc.com/comp/cardint.htm [2] : https://en.wikipedia.org/wiki/Four-wire_circuit https://en.wikipedia.org/wiki/Four-wire_circuit [3] : https://www.historyofinformation.com/detail.php?id=803 https://www.historyofinformation.com/detail.php?id=803
anyfoo 4y ago
> DNS has a class field which has 5 possible values (“internet”, “chaos”, “hesiod”, “none”, and “any”). I haven't thought about the possible values for that "class" field in a long time. It does seem interesting and extremely weird from today's perspective.
- bawolff 4y ago
  Wonder why they went with AAAA for ipv6 instead of a different class
  - bananapub 4y ago
    because no one ever used CLASS and so it was poorly supported/understood
deleted 4y ago
[deleted]
sfink 4y ago
Speculation: 7 bits are required to represent 0..100, and 7 is Just Weird, so you add an 8th to be able to do -100..100 in one addressable unit. (Or use the 8th bit to tag a variable-length numeric value.) 4 bits for 0..9 as in BCD is probably more convincing.
- magrising 4y ago
  [dead]
anyfoo 4y ago
> The word size is some multiple of the byte size. I’ve been confused about this for years, and the Wikipedia definition is incredibly vague It is extremely confusing. A "word" means different things depending on architecture, programming language, and probably a few other things that make up the context. For example, in the x86 assembly world you usually call an (usually aligned) 16 bit value a "word", a 32 bit value a "double word", and a 64 bit value a "quad word", all because the original 8086 had 16 bit wide registers that could be alternatively be used as two 8 bit registers. In other architectures or more generally other contexts, a word often relates to "how wide the bus is". But even then some of the old nomenclature bleeds into newer things that may have gotten wider busses, and it's not even always clear what bus is being referred to. Basically, unless you operate within a certain shared context, the word "word" is fuzzy and ambiguous. Maybe not quite as much as the word "object", but it's definitely up there somewhere.
- phire 4y ago
  The reason why word size is so confusing is that we started sharing architectures (partially or fully) across multiple CPU designs, baking in the word size of whatever CPU design was first. And even Architectural word size has fallen out of modern use. CPU word size for individual CPU designs much easier to define. It's not really the bus size, though it was strongly correlated until caches and bus-multipliers became a thing (For example, the PowerPC 601 has 32bit words (and 32bit registers) despite having a 64bit bus) Word size is the native operation size. The size of integer you should use in your code for the best performance. Which is why the 68000 has a 16bit word size despite having 32bit registers, because instructions for 32bit operations took a few cycles longer.
- Jasper_ 4y ago
  Yes, that's correct. The word "word" is ambiguous and has a few meanings. Where I'm from, the "word" is the unit you can load/store to memory in a single instruction. So if you can load a 32-bit quantity, that's your word size. The byte is the address granularity, while the word is the access granularity. Because of backwards compatibility, and because CPUs are far more flexible about loading more memory sizes than they traditionally have been, the meaning of "word" doesn't really matter anymore. In the context of Win32 and x86 programming, a WORD is 16 bits, a DWORD ("double word") is 32 bits, and a QWORD ("quad word") is 64 bits. That's most likely where you'll see it these days.
Terretta 4y ago
But what about 10-bit bytes* on a serial port? https://en.wikipedia.org/wiki/8-N-1 https://en.wikipedia.org/wiki/8-N-1 * words
- simonblack 4y ago
  Those are normal 8-bit bytes wrapped in a mark-space pair to allow the hardware to divine which 8-bit byte it is using. That mark-space pair is just a way of separating out the beginnings and endings of the 8-bit bytes in the bit-stream.
  - Terretta 4y ago
    Yes, that's what start / stop bits are. Though the parity bit is something else.
    - simonblack 4y ago
      But the Wiki article was for '8N1' - that's why I didn't mention it. If you add a parity bit, (say '8E1'), that makes the total 9 bits. When you wrap that in the mark-space pair that makes a total of 11 bits. Then if you have two stop-bits, as in (say '8O2') you have 8 data bits, one parity bit, one start-bit, and two stop-bits. That makes 12 bits altogether for the single data byte sent serially.
simonblack 4y ago
BCD is more accurate within the limits of the 8 digits. For instance a binary '3' is inexact, but a BCD '3' is exact. That means that currency transactions tend to work better as long as you can restrict the number of significant digits to less than the number of digits used in the BCD software. I used to use North Star BASIC back in the early 80s. North Star BASIC's default number of digits was 8, but they also supplied 10, 12 and 14 digit BASIC along with the default. You used whichever one was required for accuracy in your application.
- tantalor 4y ago
  > binary '3' is inexact Huh? Do you mean '0.3'?
  - simonblack 4y ago
    No '3'. The difference between '300', '30', '3', 0.3' etc is just the power of 10 attached to it. Having 'cut my teeth' on North Star BASIC's BCD floating point representation of numbers ( "1 + 2 = 3"), with all numbers, even integers, stored as 5-byte 8-digit BCD floating-point numbers internally. It used to drive me nuts to use Lawrence Livermore Laboratories' BASIC which used binary floating-point. You'd get things like "1 + 2 = 2.99999998" (or similar, I'm working from a 40-years ago memory here). LATER UPDATE: Sorry, I omitted the words 'floating point'. No wonder you said 'huh?'. It should have read 'Binary floating point '3' is inexact'.
    - Dylan16807 4y ago
      You're remembering wrong, unless they did something crazily non-standard. Whole numbers are represented perfectly in binary floating point. At least until you run out of digits, at which point they start rounding to even numbers, then to multiples of 4, etc. There is one spot where binary floating point has trouble compared to decimal, and that's dividing by powers of 5 (or 10). If you divide by powers of 2 they both do well, and if you divide by any other number they both do badly. If you use whole numbers, they both do well. Also even if you do want decimal, you don't want BCD. You want to use an encoding that stores 3 digits per 10 bits.
bsder 4y ago
One thing nobody talks about is that packaging technology back then was expensive. 4 bits fits into a 16 pin DIP well and cascades well. It is no coincidence that the 4004 operates on 4 bit units (BCD was also a factor). The 8008 needed an 18-pin DIP and was still far too constrained. So, your choice of unit is likely a multiple of 4.
- williamDafoe 4y ago
  I thought 8008 was a 28-pin DIP and 8080 a 40-pin DIP ...
  - bsder 4y ago
    Nope, 8008 was an 18-pin DIP. The 8080 was indeed a 40-pin DIP. However, it still needed something like 3 other support chip to demultiplex everything. It wasn't until the 8085 that you didn't need so much support circuitry.
pcwalton 4y ago
BCD was popular for a long time for values that had to be constantly printed in decimal, since doing repeated division by 10 could be slow on systems that had no wide multiplication and no barrel shifter (remember that integer division by a constant is just a wide multiply and shift). By storing in BCD you can skip the division when you go to print the value out, at the cost of making arithmetic on the value a bit more expensive. Even some video games of the 16-bit era used BCD for stuff that had to be displayed in the UI.
- euroderf 4y ago
  Knuth's MIX & MIXAL used a kind of BCD. A really strange design decision, perhaps a product of its time. A PITA to emulate.
jhallenworld 4y ago
>It looks like the next important machine in 8-bit-byte history was the Intel 8008 How about the PDP-11? Both the 360 and the PDP-11 heavily influenced microprocessor architecture.
kmoser 4y ago
I like how the author describes their thought process for how they made their best guess when they couldn't find a definitive answer, without simply assuming something or (worse) stating something as "fact" without evidence.
- goto11 4y ago
  Yes, it is a really refreshing style of writing.
MagicMoonlight 4y ago
Because it’s a power of 2… It’s embarrassing you’re even asking this. Obviously we wouldn’t use 11 bits per byte because that’s nonsense. Why don’t we use 4 bits? Because that’s like saying you could only write 2 digits for decimal numbers and never more. That’s not enough digits for practical use. I don’t want to have to write every single number as 10 pairs of two digits when I could just use numbers of a practical length.
motbus3 4y ago
There were computers which used 4 and 6 bits as well. But 8bit byte was cheaper and worked for the time so now we have 8 bit everywhere

197 points by cpach 4y ago

This was three or four jobs ago, but I remember reviewing someone's C code and they kept different collections of char* and int* pointers where they could have used a single collection of void* and the handler code would have been a lot simpler. The justification was that on this particular platform, char* pointers were differently structured to int* pointers, because char* pointers had to reference a single byte and int* pointers didn't. EDIT - I appear to have cut this story short. See my response to "wyldfire" for the rest. Sorry for causing confusion.

wyldfire 4y ago
> because char* pointers had to reference a single byte and int* pointers didn't. I must be missing some context or you have a typo. Probably most architectures I've ever worked with had `int *` refer to a register/word-sized value, and I've not yet worked with an architecture that had single-byte registers. Decades ago I worked on a codebase that used void * everywhere and rampant casting of pointer types to and fro. It was a total nightmare - the compiler was completely out of the loop and runtime was the only place to find your bugs.
- billpg 4y ago
  I forget the details (long time ago) but char* and int* pointers had a different internal structure. The assembly generated by the compiler when code accessed a char* pointer was optimized for accessing single bytes and was very different to the code generated for an int* pointer. Digging deeper, this particular microcontroller was tuned for accessing 32 bits at a time. Accessing individual bytes needed extra bit-shuffling code to be added by the compiler.
  - leeter 4y ago
    Sounds like M68K or something similar, although Alpha AXP had similar byte level access issues. A compiler on either of those platforms likely would add a lot of fix up code to deal with the fact they have to load the aligned (either 16bit in M68K case or 32Bit IIRC in Alpha) and then do bitwise and shifts depending on the pointers lower bits. Raymond's blog on the Alpha https://devblogs.microsoft.com/oldnewthing/20170816-00/?p=96825 https://devblogs.microsoft.com/oldnewthing/20170816-00/?p=96...
    - monocasa 4y ago
      M68k was byte addressable just fine. Early alpha had that issue though, as did later cray compilers. Alpha fixed it with BWX (byte word extension). Early cray compilers simply defined char as being 64bits, but later added support for the shift/mask/thick pointer scheme to pack 8 chars in a word.
      - leeter 4y ago
        Must have depended on variant, the one we used in college would throw a GP fault for misaligned access. It literally didn't have an A0 line. That said it's been over 10 years and I could be remembering the very hard instruction alignment rules as applying to data too...
        monocasa 4y ago
        16bits had to be aligned. It didn't have an A0 because of the 16bit pathway, but it did have byte select lines (#UDS, #LDS) for when you'd move.b d0,ADDR so that devices external to the CPU could see an 8-bit data access if that's what you were doing.
  - wyldfire 4y ago
    > char* and int* pointers had a different internal structure. The assembly generated by the compiler when code accessed a char* pointer was optimized for accessing single bytes and was very different to the code generated for an int* pointer. But -- they are different. Architectures where they're treated the same are probably the exception. Depending on what you mean by "very different" - most architectures will emit different code for byte access versus word access.
    - billpg 4y ago
      Accessing a 32 bit word was a simple read op. Accessing an 8 bit byte from a pointer, the compiler would insert assembly code into the generated object code. The "normal" part of the pointer would be read, loading four characters into a 32 bit register. Two extra bits were squirreled away somewhere in the pointer and these would feed into a shift instruction so the requested byte would appear in the lowest-significant 8 bits of the register. Finally, an AND instruction would clear the top 24 bits.
- mlyle 4y ago
  There are architectures where all you have is word addressing to memory. If you want to get a specific byte out, you need to retrieve it and shift/mask yourself. In turn, a pointer to a byte is a software construct rather than something there's actual direct architectural support for.
  - loeg 4y ago
    Do C compilers for those platforms transparently implement this for your char pointers as GP suggests? I would expect that you would need to do it manually and that native C pointers would only address the same words as the machine itself.
    - mlyle 4y ago
      > Do C compilers for those platforms transparently implement this for your char pointers as GP suggests? Yes. Lots of little microcontrollers and older big machines have this "feature" and C compilers fix it for you. There are nightmarish microcontrollers with Harvard architectures and standards-compliant C compilers that fix this up all behind the scenes for you. E.g. the 8051 is ubiquitous, and it has a Harvard architecture: there are separate buses/instructions to access program memory and normal data memory. The program memory is only word addressable, and the data memory is byte addressable. So, a "pointer" in many C environments for 8051 says what bus the data is on and stashes in other bits what the byte address is, if applicable. And dereferencing the pointer involves a whole lot of conditional operations. Then there's things like the PDP-10, where there's hardware support for doing fancy things with byte pointers, but the pointers still have a different format than word pointers (e.g. they stash the byte offset in the high bits, not the low bits). The C standards makes relatively few demands upon pointers so that you can do interesting things if necessary for an architecture.
    - billpg 4y ago
      Depends on how helpful the compiler is. This particular compiler had an option to switch off adding in bit shifting code when reading characters and instead set CHAR_BIT to 32, meaning strings would have each character taking up 32 bits of space. (So many zero bits, but already handles emojis.)
- kjs3 4y ago
  an architecture that had single-byte registers Wild guess, but the OP might be talking about the Intel 8051. Single-byte registers, and depending on the C compiler (and there are a few of them) 8-bit int* pointing to the first 128/256 bytes of memory, but up to 64K of (much slower) memory is supported in different memory spaces with different instructions and a 16-bit register called DPTR (and some implementations have 2 DPTR registers). C support for these additional spaces is mostly via compiler extensions analogous but different from the old 8086 NEAR and FAR pointers. I'm obviously greatly simplifying and leaving out a ton of details. Oh, yeah...on 8051 you need to support bit addressing as well, at least for the 16 bytes from 20h to 2Fh. It's an odd chip.
dahart 4y ago
It is true that on at least some platforms an int* that is 4 byte aligned is faster to access than a pointer that is not aligned. I don’t know if there are platforms where int* is assumed to be 4-byte aligned, or if the C standard allows or disallows that, but it seems plausible that some compiler somewhere defaulted to assuming an int* is aligned. Some compilers might generate 2 load instructions for an unaligned load, which incurs extra latency even if your data is already in the cache line. These days usually you might use some kind of alignment directive to enforce these things, which works on any pointer type, but it does seem possible that the person’s code you reviewed wasn’t incorrect to assume there’s a difference between those pointer types, even if there was a better option.
hoseja 4y ago
In C++, char* pointers are special in that they are exempt from aliasing rules.

ant6n 4y ago

Maybe another vague reason: when PCs came about in the era of the 8008...8086s, 64K of RAM was like a high, reasonable amount. So you need 16-bit pointers, which require exactly 2 bytes.

kleton 4y ago

ML might benefit a lot from 10bit bytes. Accelerators have a separate memory space from the CPU after all, and have their own hbm dram as close as possible to the dies. In exchange, you could get decent exponent size on a float10 that might not kill your gradients when training a model

londons_explore 4y ago
There seems to be as-yet no consensus on the best math primitives for ML. People have invented new ones for ML (eg the Brain Float16), but even then some people have demonstrated training on int8 or even int4. There isn't even consensus on how to map the state space onto the numberline - is linear (as in ints) or exponential (as in floats) better? Perhaps some entirely new mapping? And obviously there could be different optimal numbersystems for different ML applications or different phases of training or inference.

cwoolfe 4y ago

Because humans have 10 fingers and 8 is the closest power-of-two to that.

gtop3 4y ago
The article points out that a power of two bit count is actually less important than many of us assume at first.

gumby 4y ago

Author doesn't mention that several of those machines with 36-bit words had byte instructions allowing you to point at particular byte (your choice as to width, from 1-36 bits wide) and/or to stride through memory byte by byte (so an array of 3-bit fields was as easy to manipulate as any other size). Also the ones I used to program (PDP-6/10/20) had an 18-bit address space, which you may note is a CONS cell. In fact the PDP-6 (first installed in 1964) was designed with LISP in mind and several of its common instructions were LISP primitives (like CAR and CDR).

drfuchs 4y ago
Even more so, 6-bit characters were often used (supporting upper case only), in order to squeeze six characters into a word. Great for filenames and user id's. And for text files, 7-bit was enough to get upper and lower case and all the symbols, and you could pack five characters into a word. What could be better?
- deleted 4y ago
  [deleted]

IIAOPSW 4y ago

Binary coded decimal makes perfect sense if you're going to output the value to a succession of 7 segment displays (such as in a calculator). You would have to do that conversion in hardware anyway. A single repeated circuit mapping 4 bits to 7 segments gets you the rest of the way to readable output. Now that I think about it, its surprising ASCII wasn't designed around ease of translation to segmented display.

bregma 4y ago
Maybe because ASCII is from the early 1960s and 7-segment displays didn't become widespread until 15 years or so later.
kibwen 4y ago
> Now that I think about it, its surprising ASCII wasn't designed around ease of translation to segmented display. Wikipedia has a section on the design considerations of ASCII: https://en.wikipedia.org/wiki/ASCII#Design_considerations https://en.wikipedia.org/wiki/ASCII#Design_considerations
- jodrellblank 4y ago
  I love that there's a fractal world down there; from that the digits 0-9 start with bit pattern 0011 and then their value in binary to make easy convertion to/from BCD, and that control codes Start Message and End Message were positioned to maximise the Hamming distance so they're maximally different and least likely to be misinterpreted as each other in case of bits being mixed up, that 7-bit ASCII used on 8-bit tape drives left room for a parity bit for each character, that lowercase and uppercase letters differ only by the toggling of a single bit, that some of the digit/shift-symbol pairings date back to the first typewriter with a shift key in 1878...
  - jasomill 4y ago
    And my personal favorite: DEL is 1111111 so it could be punched over any other character to "delete" it from a paper tape.

908B64B197 4y ago

> (“a word is the natural unit of data used by a particular processor design”) Apparently on x86 the word size is 16 bits, even though the registers are 64 bits. That's true for the the original x86 instruction set. IA-32 has 32 bit word size and x86-64 has... you guessed it 64. 16 and 32 bit registers are still retained for compatibility reasons (just look at the instruction set!).

loeg 4y ago
Some x86 categorizations would call those dwords and qwords respectively.
stefan_ 4y ago
It's extra fun because not only are the registers retained, they were only extended. So you can use their 16 and 32 bit names to refer to smaller sized parts of them.
tom_ 4y ago
Words aeem to be always 16 bits for the x86 and derivatives - see the data types section of the software developer manual.
- dragonwriter 4y ago
  I think "word" as a datatype evolved from its original and more general computing meaning of "the natural unit of data used by a processor design" (the thing we talk about with an "x-bit processor") to "16 bits" during the period of 16-bit dominance and the explosion of computing that was happening around it. Essentially, enough stuff got written assume=ing that "word" was 16 bits (and double word, quad word, etc., had their obvious relationship) that even though the term had not previously been fixed, it would break the world to let it change, even as processors with larger word sizes (in the "natural unit of data" sense) became available, then popular, then dominant.

moremetadata 4y ago

> why was BCD popular? https://www.truenorthfloatingpoint.com/problem https://www.truenorthfloatingpoint.com/problem Floating point arithmetic has its problems. [1] Ariane 5 ROCKET, Flight 501 [2] Vancouver Stock Exchange [3] PATRIOT MISSILE FAILURE [4] The sinking of the Sleipner A offshore platform [1] https://en.wikipedia.org/wiki/Ariane_flight_V88 https://en.wikipedia.org/wiki/Ariane_flight_V88 [2] https://en.wikipedia.org https://en.wikipedia.org /wiki/Vancouver_Stock_Exchange#Rounding_errors_on_its_Index_price [3] https://www-users.cse.umn.edu/~arnold/disasters/patriot.html https://www-users.cse.umn.edu/~arnold/disasters/patriot.html [4] https://en.wikipedia.org/wiki/Sleipner_A#Collapse https://en.wikipedia.org/wiki/Sleipner_A#Collapse

elpocko 4y ago
Can you elaborate? How/why is BCD a better alternative to floating point arithmetic?
- finnh 4y ago
  floating point error. BCD guarantees you that 1/10th, 1/100th, 1/100th, etc (to some configurable level) will be perfectly accurate, without accumulating error during repeat calculations. floating point cannot do that, its precision is based on powers of 2 (1/2, 1/4, 1/8, and so on). For small values (in the range 0-1), there are _so many_ values represented that the powers of 2 map pretty tightly to the powers of 10. But as you repeat calculations, or get into larger values (say, in the range 1,000,000 - 1,000,001), the floating points become more sparse and errors crop up even easier. For example, using 32 bit floating point values, each consecutive floating point in the range 1,000,000 - 1,000,001 is 0.0625 away from the next. jshell> Math.ulp((float)1_000_000) $5 ==> 0.0625
  - elpocko 4y ago
    You can have infinite precision in pretty much any accurate representation though, no? Where is the advantage in using BCD over any other fixed point representation?
  - 4y ago

kibwen 4y ago

The reason to have a distinction between bits and bytes in the first place is so that you can have a unit of addressing that is different from the smallest unit of information. But what would we lose if we just got rid of the notion of bytes and just let every bit be addressable? To start, we'd still be able to fit the entire address space into a 64-bit pointer. The maximum address space would merely be reduced from 16 exabytes to 2 exabytes. I presume there's some efficiency reason why we can't address bits in the first place. How much does that still apply? I admit, I'd just rather live in a world where I don't have to think about alignment or padding ever again. :P

ElevenLathe 4y ago
64 bits of addressing is actually much more than most (any?) actually-existing processors have, for the simple reason that there is little demand for processors that can address 16 exabytes of memory and all those address lines still cost money.
- FullyFunctional 4y ago
  More to the point, storing the pointers cost memory. Switching from 32-bit to 64-bit effectively halved the caches for pointer-rich programs. AMD64 was a win largely due to all the things they did to compensate (including doubling the number of registers).
beecafe 4y ago
[dead]
jecel 4y ago
The TMS340 family used bit addresses, but pointers were 32 bits. https://en.wikipedia.org/wiki/TMS34010 https://en.wikipedia.org/wiki/TMS34010
cpleppert 4y ago
There are a couple of efficiency reason besides the simple fact that every piece of hardware in existence operates on data sizes in powers of the byte. To start off with it would be fantastically inefficient to build a cpu that could load arbitrary bit locations so you would either be restricted to loading memory locations that are some reasonable fraction of the internal cache line or pay a massive performance penalty to load a bit address. Realistically what would you gain by doing this when the cpu would have to divide any location by eight (or some other fraction) to figure out which cache line it needs to load? The article touches on this but having your addressable unit fit a single character is incredibly convenient. If you are manipulating text you will never worry about single bits in isolation. Ditto for mathematical operations, do you really have a need for numbers less than 255? It is a lot more convenient to think about memory locations as some reasonable unit that covers 99% of your computing use cases.

samtho 4y ago

I’m kind of disappointed that embedded computing was not mentioned. It is the longest running use-case for resource constrained applications and there are cases where not only are you using 8-bit bytes but also an 8 bit CPU. BCD is still widely used in this case to encode data to 7 segment displays or just as data is relayed over the wire between chips.

williamDafoe 4y ago
I agree completely! See my answer up above. Only 7 or 8 bits makes sense for a microprocessor, not useful if you cannot store 0-100 in a byte! With ASCII(1963) becoming ubiquitous, the 8008 had to be 8-bits! Otherwise it would have been the 7007 lol ...

williamDafoe 4y ago

I worked on the UIUC PLATO system in the 1970s : CDC-6600, 7600 cpus with 60-bit words. Back then everything used magnetic core memory and that memory was unbelievably expensive! Sewn together by women in southeast Asia, maybe $1 per word! Having 6-bit bytes on a CDC was a terrific PITA! The byte size was a tradeoffs between saving MONEY (RAM) and the hassle of shift codes (070) used to get uppercase letters and rare symbols! Once semiconductor memory began to be available (2M words of 'ECS' - "extended core storage" - actually semiconductor memory - was added to our 1M byte memory in ~1978) computer architects could afford to burn the extra 2 bits in every word to make programming easier... At about the same time microprocessors like the 8008 were starting to take off (1975). If the basic instruction could not support a 0-100 value it would be virtually useless! There was only 1 microprocessor that DID NOT use the 8-bit byte and that was the 12-bit intersil 6100 which copied the pdp-8 instruction set! Also the invention of double precision floating point made 32-bit floating point okay. From the 40s till the 70s the most critical decision in computer architecture was the size of the floating point word: 36, 48, 52, 60 bits ... But 32 is clearly inadequate. But the idea that you could have a second larger floating point fpu that handled 32 AND 64-bit words made 32-bit floating point acceptable.. Also in the early 1970s text processing took off, partly from the invention of ASCII (1963), partly from 8-bit microprocessors, partly from a little known OS whose fundamental idea was that characters should be the only unit of I/O (Unix -father of Linux). So why do we have 8-bit bytes? Thank you, Gordon Moore!

kjs3 4y ago
I worked on the later CDC Cyber 170/180 machines, and yeah there was a C compiler (2, in fact). 60-bit words, 18-bit addresses and index registers, and the choice of 5-bit or 12-bit chars. The highly extended CDC Pascal dialect papered over more of this weirdness and was much less torturous to use. The Algol compiler was interesting as well. The 180 introduced a somewhat less wild, certainly more C friendly, 64-bit arch revision. There was only 1 microprocessor that DID NOT use the 8-bit byte Toshiba had a 12-bit single chip processor at one time I'm pretty sure you could make a similar claim about. More of a microcontroller for automotive that general purpose processor, tho.
Taniwha 4y ago

PeterWhittaker 4y ago

Or maybe it was C? http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/#_36_bit_machines_and_the_persistence_of_octal http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/...

cpleppert 4y ago
The transition started before C, EBCDIC was 8 bits and ASCII was essentially a byte encoding. Unless you were designing some exotic hardware you probably needed to handle text and that was an eight bit byte. One motivation for the C type system was to extend the B programming language to support ASCII characters.

AdamH12113 4y ago

For those who are confused about bytes vs. words: The formal definition of a byte is that it's the smallest addressable unit of memory. Think of a memory as a linear string of bits. A memory address points to a specific group of bits (say, 8 of them). If you add 1 to the address, the new address points to the group of bits immediately after the first group. The size of those bit groups is 1 byte. In modern usage, "byte" has come to mean "a group of 8 bits", even in situations where there is no memory addressing. This is due to the overwhelming dominance of systems with 8-bit bytes. Another term for a group of 8 bits is "octet", which is used in e.g. the TCP standard. Words are a bit fuzzier. One way to think of a word is that it's the largest number of bits acted on in a single operation without any special handling. The word size is typically the size of a CPU register or memory bus. x86 is a little weird with its register addressing, but if you look at an ARM Cortex-M you will see that its general-purpose CPU registers are 32 bits wide. There are instructions for working on smaller or larger units of data, but if you just do a generic MOV, LDR (load), or ADD instruction, you will act on 32 register bits. This is what it means for 32 bits to be the "natural" unit of data. So we say that an ARM Cortex-M is a 32-bit CPU, even though there are a few instructions that modify 64 bits (two registers) at once. Some of the fuzziness in the definition comes from the fact that the sizes of the CPU registers, address space, and physical address bus can all be different. The original AMD64 CPUs had 64-bit registers, implemented a 48-bit address space, and brought out 40 address lines. x86-64 CPUs now have 256-bit SIMD instructions. "32-bit" and "64-bit" were also used as marketing terms, with the definitions stretched accordingly. What it comes down to is that "word" is a very old term that is no longer quite as useful for describing CPUs. But memories also have word sizes, and here there is a concrete definition. The word size of a memory is the number of bits you can read or write at once -- that is, the number of data lines brought out from the memory IC. (Note that a memory "word" is technically also a "byte" from the memory's point of view -- it's both the natural unit of data and the smallest addressable unit of data. CPU bytes are split out from the memory word by the memory bus or the CPU itself. Since computers are all about running software, we take the CPU's perspective when talking about byte size.)

fanf2 4y ago
In the Microsoft world, “word” generally means 16 bits, because their usage dates back to the 16 bit era. Other sizes are double words and quad words In the ARM ARM, a word is 32 bits, because that was the Arm’s original word size. Other sizes are half words and double words. It is a very context-sensitive term.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

sargstuff 4y ago

~60's computing grew out of the field of telecommunications [0][1]. When ASCII was released in 1963[3], integrated circuits didn't exist. Computing hardware was a build it from available, off the shelf parts endeavor. Easy to repurpose readily available 4-wire[2] to operate 4 wire relay. (2 relays -> 8 bits). ----- [0] http://ed-thelen.org/comp-hist/Reckoners-ch-4.html http://ed-thelen.org/comp-hist/Reckoners-ch-4.html [1] http://quadibloc.com/comp/cardint.htm http://quadibloc.com/comp/cardint.htm [2] : https://en.wikipedia.org/wiki/Four-wire_circuit https://en.wikipedia.org/wiki/Four-wire_circuit [3] : https://www.historyofinformation.com/detail.php?id=803 https://www.historyofinformation.com/detail.php?id=803

anyfoo 4y ago

> DNS has a class field which has 5 possible values (“internet”, “chaos”, “hesiod”, “none”, and “any”). I haven't thought about the possible values for that "class" field in a long time. It does seem interesting and extremely weird from today's perspective.

bawolff 4y ago
Wonder why they went with AAAA for ipv6 instead of a different class
- bananapub 4y ago
  because no one ever used CLASS and so it was poorly supported/understood

deleted 4y ago

[deleted]

sfink 4y ago

Speculation: 7 bits are required to represent 0..100, and 7 is Just Weird, so you add an 8th to be able to do -100..100 in one addressable unit. (Or use the 8th bit to tag a variable-length numeric value.) 4 bits for 0..9 as in BCD is probably more convincing.

magrising 4y ago
[dead]

anyfoo 4y ago

> The word size is some multiple of the byte size. I’ve been confused about this for years, and the Wikipedia definition is incredibly vague It is extremely confusing. A "word" means different things depending on architecture, programming language, and probably a few other things that make up the context. For example, in the x86 assembly world you usually call an (usually aligned) 16 bit value a "word", a 32 bit value a "double word", and a 64 bit value a "quad word", all because the original 8086 had 16 bit wide registers that could be alternatively be used as two 8 bit registers. In other architectures or more generally other contexts, a word often relates to "how wide the bus is". But even then some of the old nomenclature bleeds into newer things that may have gotten wider busses, and it's not even always clear what bus is being referred to. Basically, unless you operate within a certain shared context, the word "word" is fuzzy and ambiguous. Maybe not quite as much as the word "object", but it's definitely up there somewhere.

phire 4y ago
The reason why word size is so confusing is that we started sharing architectures (partially or fully) across multiple CPU designs, baking in the word size of whatever CPU design was first. And even Architectural word size has fallen out of modern use. CPU word size for individual CPU designs much easier to define. It's not really the bus size, though it was strongly correlated until caches and bus-multipliers became a thing (For example, the PowerPC 601 has 32bit words (and 32bit registers) despite having a 64bit bus) Word size is the native operation size. The size of integer you should use in your code for the best performance. Which is why the 68000 has a 16bit word size despite having 32bit registers, because instructions for 32bit operations took a few cycles longer.
Jasper_ 4y ago
Yes, that's correct. The word "word" is ambiguous and has a few meanings. Where I'm from, the "word" is the unit you can load/store to memory in a single instruction. So if you can load a 32-bit quantity, that's your word size. The byte is the address granularity, while the word is the access granularity. Because of backwards compatibility, and because CPUs are far more flexible about loading more memory sizes than they traditionally have been, the meaning of "word" doesn't really matter anymore. In the context of Win32 and x86 programming, a WORD is 16 bits, a DWORD ("double word") is 32 bits, and a QWORD ("quad word") is 64 bits. That's most likely where you'll see it these days.

Terretta 4y ago

But what about 10-bit bytes* on a serial port? https://en.wikipedia.org/wiki/8-N-1 https://en.wikipedia.org/wiki/8-N-1 * words

simonblack 4y ago
Those are normal 8-bit bytes wrapped in a mark-space pair to allow the hardware to divine which 8-bit byte it is using. That mark-space pair is just a way of separating out the beginnings and endings of the 8-bit bytes in the bit-stream.
- Terretta 4y ago
  Yes, that's what start / stop bits are. Though the parity bit is something else.
  - simonblack 4y ago
    But the Wiki article was for '8N1' - that's why I didn't mention it. If you add a parity bit, (say '8E1'), that makes the total 9 bits. When you wrap that in the mark-space pair that makes a total of 11 bits. Then if you have two stop-bits, as in (say '8O2') you have 8 data bits, one parity bit, one start-bit, and two stop-bits. That makes 12 bits altogether for the single data byte sent serially.

simonblack 4y ago

BCD is more accurate within the limits of the 8 digits. For instance a binary '3' is inexact, but a BCD '3' is exact. That means that currency transactions tend to work better as long as you can restrict the number of significant digits to less than the number of digits used in the BCD software. I used to use North Star BASIC back in the early 80s. North Star BASIC's default number of digits was 8, but they also supplied 10, 12 and 14 digit BASIC along with the default. You used whichever one was required for accuracy in your application.

tantalor 4y ago
> binary '3' is inexact Huh? Do you mean '0.3'?
- simonblack 4y ago
  No '3'. The difference between '300', '30', '3', 0.3' etc is just the power of 10 attached to it. Having 'cut my teeth' on North Star BASIC's BCD floating point representation of numbers ( "1 + 2 = 3"), with all numbers, even integers, stored as 5-byte 8-digit BCD floating-point numbers internally. It used to drive me nuts to use Lawrence Livermore Laboratories' BASIC which used binary floating-point. You'd get things like "1 + 2 = 2.99999998" (or similar, I'm working from a 40-years ago memory here). LATER UPDATE: Sorry, I omitted the words 'floating point'. No wonder you said 'huh?'. It should have read 'Binary floating point '3' is inexact'.
  - Dylan16807 4y ago
    You're remembering wrong, unless they did something crazily non-standard. Whole numbers are represented perfectly in binary floating point. At least until you run out of digits, at which point they start rounding to even numbers, then to multiples of 4, etc. There is one spot where binary floating point has trouble compared to decimal, and that's dividing by powers of 5 (or 10). If you divide by powers of 2 they both do well, and if you divide by any other number they both do badly. If you use whole numbers, they both do well. Also even if you do want decimal, you don't want BCD. You want to use an encoding that stores 3 digits per 10 bits.

bsder 4y ago

One thing nobody talks about is that packaging technology back then was expensive. 4 bits fits into a 16 pin DIP well and cascades well. It is no coincidence that the 4004 operates on 4 bit units (BCD was also a factor). The 8008 needed an 18-pin DIP and was still far too constrained. So, your choice of unit is likely a multiple of 4.

williamDafoe 4y ago
I thought 8008 was a 28-pin DIP and 8080 a 40-pin DIP ...
- bsder 4y ago
  Nope, 8008 was an 18-pin DIP. The 8080 was indeed a 40-pin DIP. However, it still needed something like 3 other support chip to demultiplex everything. It wasn't until the 8085 that you didn't need so much support circuitry.

pcwalton 4y ago

BCD was popular for a long time for values that had to be constantly printed in decimal, since doing repeated division by 10 could be slow on systems that had no wide multiplication and no barrel shifter (remember that integer division by a constant is just a wide multiply and shift). By storing in BCD you can skip the division when you go to print the value out, at the cost of making arithmetic on the value a bit more expensive. Even some video games of the 16-bit era used BCD for stuff that had to be displayed in the UI.

euroderf 4y ago
Knuth's MIX & MIXAL used a kind of BCD. A really strange design decision, perhaps a product of its time. A PITA to emulate.

jhallenworld 4y ago

>It looks like the next important machine in 8-bit-byte history was the Intel 8008 How about the PDP-11? Both the 360 and the PDP-11 heavily influenced microprocessor architecture.

kmoser 4y ago

I like how the author describes their thought process for how they made their best guess when they couldn't find a definitive answer, without simply assuming something or (worse) stating something as "fact" without evidence.

goto11 4y ago
Yes, it is a really refreshing style of writing.

MagicMoonlight 4y ago

Because it’s a power of 2… It’s embarrassing you’re even asking this. Obviously we wouldn’t use 11 bits per byte because that’s nonsense. Why don’t we use 4 bits? Because that’s like saying you could only write 2 digits for decimal numbers and never more. That’s not enough digits for practical use. I don’t want to have to write every single number as 10 pairs of two digits when I could just use numbers of a practical length.

motbus3 4y ago

There were computers which used 4 and 6 bits as well. But 8bit byte was cheaper and worked for the time so now we have 8 bit everywhere