Why did IBM decide to use 8 bits for EBCDIC?
7 bits per character seems reasonable, since 2^7 = 128 symbols which is enough for all English letters and special symbols.
-
1In some article they say the EBCDIC was designed for compatibility with the IBM 029 punch card codes: edwardbosworth.com/My3121Textbook_HTM/MyText3121_Ch10_V01.htm– VladCommented Jan 18, 2021 at 12:19
-
1ASCII is not sufficient. For example, it has no 'cent' or 'logical not' (the one that looks like a horizontal bar with a right-hand vertical) character– daveCommented Jan 18, 2021 at 13:06
-
4"7 bits ought to be enough for anybody" ;)– Brian HCommented Jan 18, 2021 at 13:15
-
@Vlad so EBCDIC is 8 bits since it should be compatible with IBM 029?– No Name QACommented Jan 18, 2021 at 18:34
-
1Note: EBCIDIC wasn't directly intended to be an encoding for "all English letters and special symbols." It evolved from an encoding of the various patterns of holes punched in Hollerith cards. en.wikipedia.org/wiki/EBCDIC– Solomon SlowCommented Jan 18, 2021 at 21:41
|
Show 1 more comment
1 Answer
Why did IBM decide to use 8 bits for EBCDIC?
Because the /360 ISA defined a byte to consist of 8 bits - which in turn was chosen as it allows to store two decimal numerals (BCD) within a byte.
7 bits per character seems reasonable, since 2^7 = 128 symbols which is enough for all English letters and special symbols.
For one, there is not just English - a company like IBM for sure does not want to restrict their sales to only English speaking countries? And even then, its customers don't want to serve only them as well, right?
On a more practical side, when it came to printable characters EBCDIC did cover everything ASCII did (*1) while leaving plenty room for additional use cases.
Most important: There is simply no sense in defining a character code that uses less bits than a character cell offers.
*1 - At that point its important to keep in mind that IBM was a major proponent of ASCII - in fact, next to all terminal equipment used ASCII - there was never any dispute people nowadays assume.
answered Jan 18, 2021 at 19:48
-
1Re, "no sense in defining a character code that offers less bits than..." I don't know about that. It might depend on how many different glyphs you can make room for on the drum or the chain of your line printer. Commented Jan 18, 2021 at 21:39
-
2@SolomonSlow I'm do not really get your point. What good is a 7 bit code if the unit a machine uses to handle characters (aka a byte) is fixed to 8 bit ? External codes, like printer or data transmission are a different issue, as they are defined by the media used - like ASCII being 7 bit for optimal line utilisation.– RaffzahnCommented Jan 18, 2021 at 21:50
-
1Sorry, I guess I didn't understand what "code...uses less bits..." meant. I assumed you were saying that if you had eight bits available in which to store each code point, then it would not make sense to define fewer than 256 of them. I, on the other hand, thought that there might have been a time—back before "interoperability" was a thing—when there would have been no reason to define code points for characters that the hardware was not able to display. Commented Jan 19, 2021 at 14:19
-
1I'm afraid that the statement There is simply no sense in defining a character code that uses less bits than a character cell offers is too strong and simply untrue. Defining a 7-bit character code will allow for faster transmission over serial interfaces, regardless of the character cell size.– Leo B.Commented Jan 19, 2021 at 20:13
-
1"Interchange" includes communication between the CPU and the peripherals as well. Using a 7-bit code on a machine with 8-bit bytes allows to form/verify parity in the software, and improves throughput of serial communications by >10% (e.g. 8E1 vs 7E1). Your bolded statement can be understood as "ASCII is nonsensical". Is that what you're trying to say?– Leo B.Commented Jan 19, 2021 at 21:21