Electrical and Computer Engineering

2960 readers

13 users here now

Electrical and computer engineering (ECE) community, for professionals and learners. Discuss ECE related topics here, for instance digital design, signal processing, circuit analysis, electromagnetics, microelectronics, power electronics, RF electronics, etc.

founded 2 years ago

MODERATORS

phreedf@lemmy.world

dragontamer@lemmy.world

How did we arrive at today's common word sizes? (programming.dev)

submitted 2 months ago* (last edited 2 months ago) by emotional_soup_88@programming.dev to c/ece@lemmy.world

8 comments fedilink hide all child comments

Edit: this post and my questions within were poorly formulated, mostly because I made the assumption that there is a correlation between common word sizes in CPU architecture and why I couldn't find decimal to signed binary converters online that allow me to set "word size"/number of bits I want to work with.

I am a complete beginner in the field of computers.

I am reading Code - the hidden language of computer hardware and software by Charles Petzold (2009) and I just learned how we electronically express the logic of subtraction without using a minus sign or an extra bit to indicate positive/negative: we use two's complement (yes, I realize that the most significant bit incidentally acts as the sign bit, but we don't need an extra bit). Anyway, I experimented with trying to convert both decimal and binary values into their signed counterparts, just as an exercise. To be sure that I wasn't doing anything wrong, I wanted to double check my calculations with some "decimal to signed binary calculators" on the Internet.

I was trying to express -255 in signed binary using 10 bits. I wanted to use only 10 bits because I wanted to save on resources. To express the 1000 possible values between -500 and 499, I only need 10 bits, which unsigned goes between 0 and 1023. I calculated -255 to be 1100000001 in 10-bit signed binary (because 255 is 0011111111, which you invert to get to one's complement and finally you add 1).

I couldn't find any converters on the Internet that allows me to set the maximum value/length, in this case 10 bits. I found a few that are 8 bit and a few that are 16 bit, which made me think of our gaming consoles that to my knowledge evolved in increments of 8, 16, 32, 64.

I understand that we use binary to express Boolean logic and arithmetics in electronics because regulating voltage to have transistors be in one of two values is consistent with the true/false values of Boolean logic and because of the technical difficulties in maintaining stable voltages in ternary and above.

But why didn't I find any converters online that allow me to set the bit length? Why did the gaming consoles' maximum bit length evolve in those specific increments? Are there no processor architectures of other values than these?

top 8 comments

sorted by: hot top controversial new old

[–] CannedYeet@lemmy.world 5 points 2 months ago

So it's really just a coincidence that a bit is an eighth of a byte and also an eighth of a dollar?

https://en.wikipedia.org/wiki/Bit_%28money%29

[–] AbidanYre@lemmy.world 4 points 2 months ago* (last edited 2 months ago) (1 children)

Once upon a time there were 6-bit computers. But yeah, as you've found, everything these days is 8*(2^x)

https://en.wikipedia.org/wiki/Six-bit_character_code

[–] emotional_soup_88@programming.dev 3 points 2 months ago

Thanks! Your answer led me to this, which kind of explains it:

https://en.wikipedia.org/wiki/Word_(computer_architecture)

Character size was in the past (pre-variable-sized character encoding) one of the influences on unit of address resolution and the choice of word size. Before the mid-1960s, characters were most often stored in six bits; this allowed no more than 64 characters, so the alphabet was limited to upper case. Since it is efficient in time and space to have the word size be a multiple of the character size, word sizes in this period were usually multiples of 6 bits (in binary machines). A common choice then was the 36-bit word, which is also a good size for the numeric properties of a floating point format.

After the introduction of the IBM System/360 design, which uses eight-bit characters and supports lower-case letters, the standard size of a character (or more accurately, a byte) becomes eight bits. Word sizes thereafter are naturally multiples of eight bits, with 16, 32, and 64 bits being commonly used.

So it has to do with character size, earlier six bits and today one byte/eight bits.

[–] dhork@lemmy.world 3 points 2 months ago (1 children)

There are a few different concepts to address here.

First is that we've developed a convention of 8 bits constituting a byte. And I think that is because 8 is the most convenient power of 2 which can be used for generic information. Historically, there have been attempts to encode useful information in 5 or 6 bits, and the original ASCII was a 7-bit code which encoded upper and lower case Latin characters, and simple punctuation, as well as some control characters. But it was a simple extension to pull it out to 8 bit, which is not only a power of 2 but also can be expressed fully by 2 hexadecimal characters.

Then, as 8-bit lead to 16-bit and beyond, it is convenient to stick with the same power of 2 representation. It is also convenient to stick with the Hexadecimal notation. Plus, it makes it easier to break down larger integer values into smaller chunks if they are all 8 bit. (As long as you understand endianness....)

But, as to your question why many online calculators don't let you change the bit length, that is explained because it is trivial to extend these values. You can represent a signed 2's complement value of a certain length in a larger counter by simply extending the MSB.

[–] emotional_soup_88@programming.dev 2 points 2 months ago (1 children)

Thanks! I have no idea what endianness is, except for hear "big endian" in some CS-related presentation a while back... I'll read up on it!

As for my questions and your answer, would it be correct to say then that it's about scalability? That one byte being eight bits scales efficiently in binary?

[–] dhork@lemmy.world 2 points 2 months ago (1 children)

would it be correct to say then that it's about scalability? That one byte being eight bits scales efficiently in binary?

Kind of, but in his case it's all about human scalability. 8 bits turns out to be a convenient chunk to encode characters in. ASCII is 7 bits, but it turns out to be only useful for things in the Latin alphabet. System designers decided that it was worth retaining the 8th bit (even if it was unused in flat text files). There is a "extended" 8-bit ASCII standard but the 7-bit standard was always more widespread. Why arent all of our bytes 7 bits, then? I stand by my personal theory that it is because it is very easy to represent the full range of 8 bits in Hex.

Later on, the Unicode folks brought some utility to that 8th bit. UTF-8 is an encoding that mirrors ASCII in the lower 7 bits, but can be extended into multi-byte characters and represent other scripts too. An overwhelming amountof Internet content is actually encoded in UTF-8. These will render correctly in an editor that only understands 7-bit ASCII, except for some things like the Euro symbol, which are multi-byte constructs that require that 8th bit in order to be recognized.

So maybe in addition to looking into Endianness, you should spend some time reading up on Unicode and it's history to get to the answer you are looking for.

[–] emotional_soup_88@programming.dev 1 points 2 months ago

Amazing! Seems I posted in the right "sub". I'll check out Unicode tonight, perhaps as a "prelude" to endianness. :)

[–] roguelazer@lemmy.world 2 points 2 months ago

To answer your specific question: no. There have been and continue to be lots of CPUs that have things that could plausibly be called a "bit size" that aren't a power of 2. Note that the "bit size" can refer to a few things (the width of the bus between the CPU and memory, the native size of a pointer, and/or the native width of the arithmetic units). I'll give examples of each.

On essentially every "64-bit" computer, the bus to memory is not 64 bits wide. For example, the Apple M4 ARM CPUs are 64-bit but have a 128-bit memory bus over which they communicate something like 43-bit physical addresses. ARM has always been this way; the original 32-bit ARM1 had 26-bit physical addresses.

As to pointer size, the best example is probably the currently-being-developed CHERI architecture which is 64-bit arithmetic but 129-bit pointers.

For an arithmetic unit example, the floating-point unit on Intel CPUs was traditionally 80 bits wide. These days, it's emulated on a 128-bit wide SSE unit but you still see 80 bits in code a bit.