[HN Gopher] ASCII Double-Murder (2022)
___________________________________________________________________
ASCII Double-Murder (2022)
Author : tomohawk
Score : 85 points
Date : 2023-03-03 01:11 UTC (1 days ago)
(HTM) web link (madned.substack.com)
(TXT) w3m dump (madned.substack.com)
| mbnull wrote:
| I read it in my head with the voice of Ken Nordine of Word Jazz
| Colors fame.
| raldi wrote:
| > She gave me that big 4C4F4C laugh of hers. It gets me every
| time.
|
| Anyone get this joke?
| jfk13 wrote:
| It's ASCII: 0x4C = 'L', 0x4F = 'O', 0x4C = 'L'.
| raldi wrote:
| Thanks; that makes a lot more sense than Asparagus Gray.
| thayne wrote:
| Octal isn't quite dead. It's still used for unix permissions,
| because a single digit of octal corresponds to the three bit of
| read, write, and execute access.
| hilbert42 wrote:
| Ha, _' The 360'_ was my first computer gig. I remember it well.
|
| _By then, Hex ruled the roost and Octal had gone AWOL but kept
| getting mentioned in dispatches._
| jameshart wrote:
| This is a damn cover-up. Octal's still around - working a gig for
| the POSIX crew as an enforcer, controlling access to files down
| in the directory system. Sure, he wears a mask that disguises his
| bits as _r_ , _w_ and _x_ , but it's definitely him.
| af3d wrote:
| Some enforcer. At one time or another he was hired to take out
| Binary. (Word has it, shifty Binary was sowing divisions
| between the Byte gang). Octal was even told that Binary would
| be hanging out at the Brawling Bits Biker Club at around 10.
| But wouldn't you know it, the guy shows up 6 hours late! SMH
| kens wrote:
| One problem with this theory that ASCII killed off octal is that
| ASCII was introduced in 1963, while octal was popular into the
| mid-1970s. The real reason that hex beat octal is 16-bit words.
| It's trivial to break a 16-bit word into two bytes with hex, but
| it's a mess in octal.
|
| To make this concrete, suppose we have the bytes 1, 2, 3, 4 in
| 16-bit memory. In hex, this is 0102 0304. In octal, this is
| 000402 001404. Hex makes it trivial to see the bytes, extract
| them, byte-swap, etc. In octal, you need to sit down and think.
| I've worked on a 16-bit octal machine (Xerox Alto) and after
| about 2 minutes it's obvious why hex won.
| userbinator wrote:
| On the other hand, x86 (and 8080/5/Z80) instruction encodings
| look far more sensical in octal, due to their 2-3-3 field
| arrangement, yet the official documentation has always used
| hex.
| kens wrote:
| I agree with you 100% there. The Datapoint 2200 (which the
| 8008 cloned) used octal for its instructions and the
| instruction decoding is almost trivial to understand.
| Unfortunately, Intel used hexadecimal for the documentation.
| In hex, you can kinda see some patterns in the opcodes. The
| 6502, on the other hand, arranges the fields 3-3-2, so octal
| is no help even though the fields use bit triples.
|
| Discussion of "x86 is an octal machine":
| https://news.ycombinator.com/item?id=30409100
| jameshart wrote:
| All of which makes sense since you know eight bit bytes and
| sixteen bit words are going to win the day. But when twelve bit
| words are still in contention, it isn't so cut and dried.
|
| And ASCII is what pushes you towards preferring eight bit
| bytes.
| kens wrote:
| What pushed computing toward eight bit bytes is the IBM
| System/360 (1964) which dominated the computing industry at
| the time. It used 8-bit EBCDIC (with ASCII as an
| afterthought). If ASCII didn't exist, we'd still be using
| byte-based systems and hexadecimal.
|
| Prior to System/360, business data processing typically used
| 6-bit characters (e.g. IBM 1401), which only gave you upper
| case. Scientific processing used whatever word size gave the
| desired accuracy, so it was totally reasonable to have a
| 15-bit computer or a 26-bit computer. Powers of two for the
| word size are convenient for slicing up words into smaller
| pieces and for specifying a bit in the word. But you also
| have systems like the Four Phase, which used 24-bit words
| consisting of 3 bytes. (Which turned out to be a mess when
| you try to extract bytes from words.)
| jameshart wrote:
| But you only care about the difficulty of extracting eight-
| bit bytes from words because you need to do things like
| interoperate with protocols or storage media based on eight
| bit bytes, or eight bit parallel interfaces.
|
| If _everything_ were based on a different basic 'byte' size
| that objection would go away.
|
| Sure, oddball things that used 8-bit data would exist and
| you'd need to work with them - but in our 8-bit world
| oddball things based on 10-bit protocols exist and we live
| with the impedance mismatches that causes.
| codeflo wrote:
| It's easy with hindsight, but there must have been people
| back then who foresaw that power-of-two machine words are
| almost as necessity as you scale up (8 -> 16 -> 32 -> 64
| bits).
| jameshart wrote:
| But that's building off '8' as the starting unit. I can
| definitely imagine a counterfactual where 12bit bytes
| became the basic building block. Imagine if early text
| encoding had assumed that more than the Latin alphabet
| would be useful (say if standards had been being set by
| Japanese companies rather than American ones?) - an early
| maybe 10bit text standard would have weighed towards 12bit
| bytes being more useful. 12bit bytes also work great for
| encoding RGB values for video - and RGBA for image
| processing.
|
| The importance of having a power-of-two bits might just not
| be that big a deal held up against all those upsides. After
| all, when do you really care about how many bits it takes
| to store an index into a byte, or a word, anyway? The <<
| and >> bitshift operators even on a 64bit number are only
| using 6 bits of their operand, so even on an 8-bit-centric
| architecture you're not realizing any great synergy with
| the powers of two.
|
| Is it so hard to imagine instead a 12-bit era, followed by
| a 24-bit revolution, and maybe now we'd be talking about
| the end of 48-bit systems as the 96-bit processors start
| coming to market?
| nine_k wrote:
| Historically, there were a number of 24-bit, 36-bit, and
| 48-bit CPU designs; some modern DSPs still have 24-bit
| ALUs, IIRC.
|
| Interestingly, all these numbers divide cleanly by 8,
| except for 36. I never heard about 12-bit CPUs though.
|
| Where octal representation shone was 3-bit fields in some
| CPU code, especially in the venerable PDP-11. Using octal
| representation for them was the only sane way.
|
| Coincidentally, much of the UNIX was built on various PDP
| machines.
|
| Also, early TTYs, that is, actual mechanical teletypes,
| were often 6-bit, which also sits well with octal
| encoding.
| jameshart wrote:
| > I never heard about 12-bit CPUs though.
|
| The original article points to the DEC PDP-8. That 12-bit
| architecture, which built on the PDP-5, also 12-bit,
| wound up in microprocessor form in the Intersil 6100, and
| DEC actually tried to build a desktop microcomputer based
| on that chip - the DECmate
| (https://en.wikipedia.org/wiki/DECmate).
|
| The 16-bit PDP-11 was literally the result of typical DEC
| indecision, infighting and hedging in the face of
| increasing importance of ASCII processing (and ultimately
| a response to a bunch of their engineers who had seen
| that writing on the wall leaving and founding Data
| General).
|
| Like so many things in computer history, if DEC had had
| its shit together, things would have worked out very
| differently.
| codeflo wrote:
| > I can definitely imagine a counterfactual where 12bit
| bytes became the basic building block.
|
| It's definitely fun to imagine. I personally have a soft
| spot for a hypothetical ternary architectures, where the
| "trits" are either -1, 0 or 1. There's a mathematical
| elegance to that number system that binary can't match.
|
| > 12bit bytes also work great for encoding RGB values for
| video
|
| Can you elaborate, do you mean historically? The more
| bits the better, of course -- I get why 12 are better
| than 8, but it's not clear to me why you would want to
| stop at 12 bits. And if you don't stop there, what's the
| advantage?
|
| > The << and >> bitshift operators even on a 64bit number
| are only using 6 bits of their operand, so even on an
| 8-bit-centric architecture you're not realizing any great
| synergy with the powers of two.
|
| 6 bits is still cleaner than the 6.58 bits required to
| encode shifts for this hypothetical 96-bit architecture,
| just use the lowest 6 address lines.
|
| And in general I think there are more places where stuff
| like this comes up than is apparent at first glance. How
| many bytes in a page? How many pages in a RAM chip? How
| many address lines and data lines?
|
| In the current era, RAM chips are agnostic about word
| size (as long as it's a power of two) because what they
| actually address are these much larger pages that chips
| can cut up in any way they want. Perhaps if everything
| standardized to 12 bits as the base at once, you could
| solve that or find workarounds, but I think would be
| mathematically tedious at every turn. It's so easy to
| just chop off a few bits and not worry about it.
| jameshart wrote:
| To elaborate on "12bit bytes also work great for encoding
| RGB values for video":
|
| I just mean that it's easy to encode an RGB value as
| three four-bit values in a 12-bit number. Aligning
| 'memory addresses' to 'pixels' would simplify video
| hardware. Historically, 4096-color modes based on
| 12-bits-per-pixel were used (notably on the Amiga), in
| spite of byte-alignment issues. And of course 24-bit
| pixels would map to the common 16m colors we all know and
| love. 8, 16 and 32 bit architectures have always had
| compromises of one sort or another for storing three
| color channels - I half feel like the ubiquity of ARGB in
| modern graphics is down to our finally accepting that
| storage and memory are now cheap enough we should stop
| worrying about waste, pad out pixels with another
| channel, and just find a use for it. Transparency? Sure,
| why not.
|
| Regarding how RAM is laid out... a lot of early computers
| used ram chips striped by bit - so they'd have eight ram
| chips all wired to the same address bus, with each
| responsible for storing one data line for each address.
| Twelve bit memory is just laying four more data lines and
| adding four more chips.
|
| In my hypothetical counterfactual universe, obviously if
| 12 bit bytes win, later memory architectures are built
| around 12/24/48/96 bit data buses, so whatever paging and
| slicing they do would be within that model.
| interfixus wrote:
| Superb. But can't let go without obligatory Watterson:
|
| https://www.gocomics.com/calvinandhobbes/1991/02/26
| JasonFruit wrote:
| The dead-on imitation of hard-boiled detective prose gets me
| every time. "I always leave when the talk gets philosophical,"
| indeed!
| codeflo wrote:
| > she said the star performer was a guy named ASCII, who really
| didn't get along at all with Octal
|
| I'm not convinced. ASCII is 7 bits only, which doesn't fit much
| better into 2*4 than into 3*3. It's not like the extra bit would
| be "wasted" anywhere, both octal and hex are only for displaying
| numbers, not actually used in memory.
| gweinberg wrote:
| Good point. But why would anyone want to display a number in
| octal anywhere, ever?
| the_af wrote:
| This was a pretty fun read. I enjoyed the pastiche.
___________________________________________________________________
(page generated 2023-03-04 23:01 UTC)