From: John Cowan <cowan@ccil.org>
To: M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] 2^n-bit operands (Was reviving a bit of WWB)
Date: Wed, 3 Feb 2021 15:07:46 -0500 [thread overview]
Message-ID: <CAD2gp_Rjn2z1SMitQ0VX-NASHdEJ3GcmeZaaTq_iCHwF4xiGVA@mail.gmail.com> (raw)
In-Reply-To: <CAKH6PiUuV3tLRH=Tmy3ppwT2Ski60_=M+UuCDXr+zTPBer823A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]
On Wed, Feb 3, 2021 at 9:55 AM M Douglas McIlroy <
m.douglas.mcilroy@dartmouth.edu> wrote:
With the 360 series, IBM fully committed to multiple operand sizes. DEC
> followed suit and C naturalized the idea into programmers' working
> vocabulary.
>
The steady expansion of character set sizes also had a great deal to do
with it. The various 6-bit character sets were fine as long as the
industry was okay with English-only SHOUTING. When that was outgrown,
7-bit ASCII and 8-bit EBCDIC on multiple-of-6 word sizes (as were found on
the big-endian DEC machines up to the PDP-10) were annoying to use.
On the 12-bit PDP-8, where I cut my teeth, ASCII was stored as
HHHHAAAAAAAA followed by LLLLBBBBBBBB, where the As represent the first
character, the Bs the second, and the Hs and Ls the third. Padding was
done with NUL, which meant that, for example, the TTY driver simply filled
its read buffer with 0000AAAAAAAA 0000BBBBBBBB, which made rubout handling
much simpler. Textual programs reading from it would already be set up to
ignore NULs.
On the 36-bit PDP-10, things were better: the sign bit was mostly ignored
and five 7-bit ASCII characters were packed into each word, again with NUL
padding. (Line editors turned on the sign bit to indicate that this word
held an explicit ASCII line number.)
John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org
Original line from The Warrior's Apprentice by Lois McMaster Bujold:
"Only on Barrayar would pulling a loaded needler start a stampede toward
one."
English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk
to
lose support instead of finding it when you threat with the charged weapon."
[-- Attachment #2: Type: text/html, Size: 3504 bytes --]
next prev parent reply other threads:[~2021-02-03 20:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 14:55 M Douglas McIlroy
2021-02-03 20:07 ` John Cowan [this message]
2021-02-03 20:51 ` Lars Brinkhoff
2021-02-03 21:10 ` Rich Morin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD2gp_Rjn2z1SMitQ0VX-NASHdEJ3GcmeZaaTq_iCHwF4xiGVA@mail.gmail.com \
--to=cowan@ccil.org \
--cc=m.douglas.mcilroy@dartmouth.edu \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).