On Jun 27, 2017, at 3:02 PM, Keith Medcalf <kmedc...@dessus.com> wrote: > >> The whole point of >> specifying a format as 7 bits is that the 8th bit is ignored, or >> perhaps used in an implementation-defined manner, regardless of whether >> the 8th bit in a char is available or not. > > ASCII was designed back in the days of low reliability serial communications > -- you know, back when data was sent using 7 bit data + 1 parity bits + 2 > stop bits -- to increase the reliability of the communications. A "byte" was > also 9 bits. 8 bits of data and a parity bit.
Before roughly the mid 1970s, the size of a byte was whatever the computer or communications system designer said it was. Even within a single computer + serial comm system, the definitions could differ. For this reason, we also have the term “octet,” which unambiguously means an 8-bit unit of data. The 9-bit byte is largely a DEC-ism, since their pre-PDP-11 machines used a word size that was an integer multiple of 6 or 12. DEC had 12-bit machines, 18-bit machines, and 36-bit machines. There was even a plan for a 24-bit design at one point. A common example would be a Teletype Model 33 ASR hardwired by DEC for transmitting 7-bit ASCII on 8-bit wide paper tapes with mark parity, fed by a 12-bit PDP-8 pulling that text off an RK05 cartridge disk from a file encoded in a 6-bit packed ASCII format. 6-bit packed ASCII schemes were common at the time: to efficiently store plain text in the native 12-, 18-, or 36-bit words, programmers would drop most of the control characters and punctuation, as well as either dropping or shift-encoding lowercase. That isn’t an innovation from the DEC world, either: Émile Baudot came up with basically the same idea in his eponymous 5-bit telegraph code in 1870. You could well say that Baudot code uses 5-bit bytes. (This is also where the data communications unit “baud” comes from.) The 8-bit byte standard — and its even multiples — is relatively recent in computing history. You can point to early examples like the 32-bit IBM 360 and later ones like the 16-bit Data General Nova and DEC PDP-11, but I believe it was the flood of 8-bit microcomputers in the mid to late 1970s that finally and firmly associated “byte” with “8 bits”. > Nowadays we use 8 bits for data with no parity True parity bits (as opposed to mark/space parity) can only detect a 1-bit error. We dropped parity checks when the data rates rose and SNR levels fell to the point that single-bit errors were a frequent occurrence, making parity checks practically useless. > no error correction The wonder, to my mind, is that it’s still an argument whether to use ECC RAM in any but the lowest-end machines. You should have the option to put ECC RAM into any machine down to about the $500 level by simply paying a ~25% premium on the option cost for non-ECC RAM, but artificial market segmentation has kept ECC a feature of the server and high-end PC worlds only. This sort of penny-pinching should have gone out of style in the 1990s, for the same reason Ethernet and USB use smarter error correction than did RS-232. We should have flowed from parity RAM at the high end to ECC RAM at the high end to ECC everywhere by now. > and no timing bits. Timing bits aren’t needed when you have clock recovery hardware, which like ECC, is a superior technology that should be universal once transistors become sufficiently cheap. Clock recovery becomes necessary once SNR levels get to the point they are now, where separate clock lines don’t really help any more. You’d have to apply clock recovery type techniques to the clock line if you had it, so you might as well apply it to the data and leave the clock line out. > Cuz when things screw up we want them to REALLY screw up ... and remain > undetectable. Thus the move toward strongly checksummed filesystems like ZFS, btrfs, HAMMER, APFS, and ReFS. Like ECC, this is a battle that should be over by now, but we’re going to see HFS+, NTFS, and extfs hang on for a long time yet because $REASONS. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
