Computer Old Farts Forum
 help / color / mirror / Atom feed
From: crossd at (Dan Cross)
Subject: [COFF] [TUHS] v7 K&R C
Date: Mon, 18 May 2020 12:11:00 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, May 17, 2020 at 12:24 PM Paul Winalski <paul.winalski at>

> On 5/16/20, Steffen Nurpmeso <steffen at> wrote:
> >
> > Why was there no byte or "mem" type?
> These days machine architecture has settled on the 8-bit byte as the
> unit for addressing, but it wasn't always the case.  The PDP-10
> addressed memory in 36-bit units.  The character manipulating
> instructions could deal with a variety of different byte lengths:  you
> could store six 6-bit BCD characters per machine word,

Was this perhaps a typo for 9 4-bit BCD digits? I have heard that a reason
for the 36-bit word size of computers of that era was that the main
competition at the time was against mechanical calculator, which had
9-digit precision. 9*4=36, so 9 BCD digits could fit into a single word,
for parity with the competition.

6x6-bit data would certainly hold BAUDOT data, and I thought the Univac/CDC
machines supported a 6-bit character set?  Does this live on in the Unisys
1100-series machines? I see some reference to FIELDATA online.

I feel like this might be drifting into COFF territory now; Cc'ing there.

or five ASCII
> 7-bit characters (with a bit left over), or four 8-bit characters
> (ASCII plus parity, with four bits left over), or four 9-bit
> characters.
> Regarding a "mem" type, take a look at BLISS.  The only data type that
> language has is the machine word.
> >   +getfield(buf)
> >   +char buf[];
> >   +{
> >   +       int j;
> >   +       char c;
> >   +
> >   +       j = 0;
> >   +       while((c = buf[j] = getc(iobuf)) >= 0)
> >   +       if(c==':' || c=='\n') {
> >   +               buf[j] =0;
> >   +               return(1);
> >   +       } else
> >   +               j++;
> >   +       return(0);
> >   +}
> >
> > so here the EOF was different and char was signed 7-bit it seems.
> That makes perfect sense if you're dealing with ASCII, which is a
> 7-bit character set.

To bring it back slightly to Unix, when Mary Ann and I were playing around
with First Edition on the emulated PDP-7 at LCM+L during the Unix50 event
last USENIX, I have a vague recollection that the B routine for reading a
character from stdin was either `getchar` or `getc`. I had some impression
that this did some magic necessary to extract a character from half of an
18-bit word (maybe it just zeroed the upper half of a word or something).
If I had to guess, I imagine that the coincidence between "character" and
"byte" in C is a quirk of this history, as opposed to any special hidden
meaning regarding textual vs binary data, particularly since Unix makes no
real distinction between the two: files are just unstructured bags of
bytes, they're called 'char' because that was just the way things had
always been.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

       reply	other threads:[~2020-05-18 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <077a01d62b08$e696bee0$b3c43ca0$>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
2020-05-18 16:11             ` crossd [this message]
2020-05-18 16:30               ` clemc
2020-05-18 21:18               ` ron
2020-05-19  4:00               ` [COFF] UNIVAC and other character sets (was: v7 K&R C) grog
     [not found] <>
     [not found] ` <>
     [not found]   ` <m1jYCHm-0036tPC@more.local>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
     [not found]             ` <>
     [not found]               ` <>
     [not found]                 ` <>
     [not found]                   ` <>
2020-05-14 17:37                     ` [COFF] [TUHS] v7 K&R C athornton
2020-05-14 17:38                       ` lm

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \

* 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).