Possible reasons for 8-bit bytes

https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes/

by cpach • 3 years ago

197 118 3 years ago

billpg4• 3 years 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.

wyldfire2• 3 years 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.

billpg4• 3 years 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.

mlyle3• 3 years 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.

kjs32• 3 years 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• 3 years 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• 3 years ago

In C++, char* pointers are special in that they are exempt from aliasing rules.

ant6n• 3 years 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• 3 years 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• 3 years 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• 3 years ago

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

gtop3• 3 years ago

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

gumby• 3 years 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• 3 years 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?

908B64B197• 3 years 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!).

loeg3• 3 years ago

Some x86 categorizations would call those dwords and qwords respectively.

stefan_• 3 years 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_• 3 years ago

Words aeem to be always 16 bits for the x86 and derivatives - see the data types section of the software developer manual.

dragonwriter• 3 years 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.

IIAOPSW2• 3 years 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.

kibwen2• 3 years 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

jodrellblank• 3 years 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...

kps2• 3 years ago

The Wikipedia section is pretty good now. There are a few notable omissions. The backslash was added so that logical ∧ and ∨ could be written as /\ and \/ — two operators for the price of one. The characters : and ; were considered the least important punctuation, so they were placed immediately after 9, where they could be replaced by single-character 10 and 11 for shillings. And the characters *+,-./ were placed in rows 10-15 so that they could easily be combined with the digits to make a 16-bit subset suitable for writing numbers and basic arithmetic.

bregma• 3 years ago

Maybe because ASCII is from the early 1960s and 7-segment displays didn't become widespread until 15 years or so later.

karmakaze2• 3 years ago

EBCDIC 1963/64 (i.e. E-BCD-IC) was an extension of BCD to support characters.

[0] https://en.wikipedia.org/wiki/EBCDIC

dhosek• 3 years ago

370 Assembly had a machine operation for converting an EBCDIC-encoded digit string into an internal integer which seemed odd at the time, but the more I think about it (converting digit strings to integers is a surprisingly subtle operation), the more it makes sense to do this at the lowest level possible.

The other interesting thing about EBCDIC was that character codes with A–F in the lower nibble of the code were generally unused or reserved for uncommon characters. This restriction didn’t apply to the upper nibble (most notably the digits were encoded as F0–F9).

moremetadata2• 3 years ago

why was BCD popular?

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

[2] 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

[4] https://en.wikipedia.org/wiki/Sleipner_A#Collapse

elpocko3• 3 years ago

Can you elaborate? How/why is BCD a better alternative to floating point arithmetic?

finnh• 3 years 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

moremetadata2• 3 years ago

For the reasons others have mentioned, plus BCD doesnt suffer data type issues in the same way unless the output data type is wrong, but then the coder has more problems than they realise.

The only real disadvantage for BCD is its not as quick as Floating point arithmetic, or bit swapping data types, but with todays faster processors, for most people I'd say the slower speed of BCD is a non issue.

Throw in other hardware issues, like bit swapping in non ECC memory and the chances of error's accumulate if not using BCD.

pestatije• 3 years ago

BCD is not floating point

coldtea2• 3 years ago

That's the parent's point

kps2• 3 years ago

BCD and floating point are orthogonal. Some early computer systems had BCD floating point, as did (do?) most scientific calculators.

KMag• 3 years ago

The Ariane bug was an overflow casting 64-bit floating point to 16-bit integer. It would still have overflowed at the same point if it had been 64-bit decimal floating point using the same units. The integer part of the floating point number still wouldn't have fit in a signed 16-bit integer.

As per the provided link, the Patriot missile error was 24-bit fixed point arithmetic, not floating point. Granted, a fixed-point representation in tenths of a second would have fixed this particular problem, as would have using a clock frequency that's a power of 1/2 (in Hz). Though, using a base 10 representation would have prevented this rounding error, it would also have reduced the time before overflow.

I think IEEE-754r decimal floating point is a huge step forward. In particular, I think there was a huge missed opportunity in defining open spreadsheet formats that decimal floating point option wasn't introduced.

However, binary floating point rounding is irrelevant to the Patriot fixed-point bug.

It's not reasonable to expect accountants and laypeople to understand binary floating point rounding. I've seen plenty of programmers make goofy rounding errors in financial models and trading systems. I've encountered a few developers who literally believed the least significant few bits of a floating point calculation are literally non-deterministic. (The best I can tell, they thought spilling/loading x87 80-bit floats from 64-bit stack-allocated storage resulted in whatever bits were already present in the low-order bits in the x87 registers.)

kibwen2• 3 years 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• 3 years 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.

FullyFunctional2• 3 years 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).

jecel• 3 years ago

The TMS340 family used bit addresses, but pointers were 32 bits.

https://en.wikipedia.org/wiki/TMS34010

cpleppert2• 3 years 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.

aleph_minus_one• 3 years 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.

The Intel iAPX 432 did use bit-aligned instructions:

https://en.wikipedia.org/w/index.php?title=Intel_iAPX_432&ol...

samtho• 3 years 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.

williamDafoe3• 3 years 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 ...

williamDafoe3• 3 years 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!

kjs32• 3 years 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.

Taniwha2• 3 years ago

yup - we bought 1.5Mb of core for our B6700 for ~US$1.25M (in 1976 dollars) - as a 48(+4) bit machine it either had 6 8-bit bytes or 8 6-bit bytes. In practice ASCII had 7-bit characters and EBCDIC 7-8 bit ones. Teletypes (6-bit) were still around.

From the beginning right up to the birth of microprocessors computer architects were still experimenting around these tradeoffs - around the late 70s it all jelled into 8 bit bytes and power of 2 word sizes

I think that 8 bits is a nice round number is you move to a memory model that is an array of bytes and an array of words - making everything a power of 2 in size makes the hardware simpler (much the same reason why bcd, and decimal arithmetic have largely disapeared)

Taniwha2• 3 years ago

having said that in the 90s I was once on a design team that built a CPU with 8 9-bit bytes in a word and an 81-bit instruction (9 9-bit bytes).

It was a DSP, memory was still relatively expensive and MPEG needed 9-bit delta frames, however DRAMS with byte parity were available so it was a price point that made sense at the time

miohtama• 3 years ago

The core dump of this systems must have been heavy.

photochemsyn• 3 years ago

One of the most entertaining visual expositions of how magnetic core memory works is this little 14-min overview of the Saturn V memory system, "How did NASA steer the Saturn V":

https://youtu.be/dI-JW2UIAG0

jhallenworld2• 3 years ago

I used a DECSYSTEM-20: it had variable "byte" size.. for ASCII you could (and normally did) pack 5 7-bit bytes into its 36-bit words. There were instructions to read and write bytes of any size you want out of these words.

The C compiler used 9-bit bytes, just to make pointer arithmetic simpler.

PeterWhittaker• 3 years ago

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

cpleppert2• 3 years 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.

AdamH121132• 3 years 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• 3 years 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.

AdamH121132• 3 years 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

Ah, yes. That terminology is still used in the Windows registry, although Windows 10 seems to be limited to DWORD and QWORD. Probably dates back to the 286 or earlier. :-)

ajross2• 3 years ago

FWIW, those conventions come from Intel originally, Microsoft took it from them. ARM borrowed from VAX Unix conventions, who got it from DEC.

FullyFunctional2• 3 years ago

It's not entirely historically accurate. Early machines were "word addressable" (where the words wasn't 8-bit) which by your definition should have been called "byte addressable".

There were even bit addressable computers, but it didn't catch on :)

If it wasn't for text, there would be nothing "natural" about an 8-bit byte (but powers-of-two are natural in binary computers).

kevin_thibedeau• 3 years ago

There were even bit addressable computers, but it didn't catch on

Cortex-M has bit addressability as a vendor option. They're mapped onto virtual bytes in a region of memory so the core doesn't have to handle them in a special way.

IAmLiterallyAB• 3 years ago

"byte" has become so synonymous with 8 bits that I like to use the term "addressable unit".

I found this LLVM forum thread discussing it interesting: https://groups.google.com/g/llvm-dev/c/s2yuELeQMA8

And related PR https://reviews.llvm.org/D61725

sargstuff• 3 years 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

[1] http://quadibloc.com/comp/cardint.htm

[2] https://en.wikipedia.org/wiki/Four-wire_circuit

[3] https://www.historyofinformation.com/detail.php?id=803

anyfoo2• 3 years 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• 3 years ago

Wonder why they went with AAAA for ipv6 instead of a different class

bananapub• 3 years ago

because no one ever used CLASS and so it was poorly supported/understood

sfink• 3 years 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.

anyfoo2• 3 years 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.

phire3• 3 years 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_• 3 years 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.

userbinator2• 3 years ago

On the other hand, I haven't seen a dword referring to anything other than 32 bits, nor a qword, 64. There's also oword, which is 128 bits.

phire3• 3 years ago

PowerPC, ARM, AArch64, RISC-V and MIPS all use dword to refer to 64bit data.

And AArch64 also uses qword to refer to 128 bit data types.

grishka• 3 years ago

TIL that word/dword/qword comes from x86 assembly. I always thought these were invented by Microsoft as part of win16 and then carried into win32 for source-level backwards compatibility.

Terretta2• 3 years ago

But what about 10-bit bytes* on a serial port?

https://en.wikipedia.org/wiki/8-N-1

* words

simonblack4• 3 years 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.

Terretta2• 3 years ago

Yes, that's what start / stop bits are. Though the parity bit is something else.

simonblack4• 3 years 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• 3 years ago

binary '3' is inexact

Huh? Do you mean '0.3'?

simonblack4• 3 years 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'.

Dylan168072• 3 years ago

Binary is significantly more accurate for most numbers.

If you use 12 digit BCD to store 1/3, you get .333 333 333 333 000 000

If you use the same number of bits for binary, you get .333 333 333 333 333 925

bsder2• 3 years 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.

williamDafoe3• 3 years ago

I thought 8008 was a 28-pin DIP and 8080 a 40-pin DIP ...

bsder2• 3 years 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• 3 years 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• 3 years 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.

jhallenworld2• 3 years 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• 3 years 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• 3 years ago

Yes, it is a really refreshing style of writing.

MagicMoonlight• 3 years 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• 3 years 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

Possible reasons for 8-bit bytes

Related Stories