Computer Old Farts Forum
 help / color / mirror / Atom feed
From: grog at lemis.com (Greg 'groggy' Lehey)
Subject: [COFF] UNIVAC and other character sets (was: v7 K&R C)
Date: Tue, 19 May 2020 14:00:08 +1000	[thread overview]
Message-ID: <20200519040008.GK1670@eureka.lemis.com> (raw)
In-Reply-To: <CAEoi9W6jwA1_MGD11Sc837YMgDfGJWzAQFCyrbrx72a1PJ3ViA@mail.gmail.com>

On Monday, 18 May 2020 at 12:11:00 -0400, Dan Cross wrote:
> On Sun, May 17, 2020 at 12:24 PM Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>> On 5/16/20, Steffen Nurpmeso <steffen at sdaoden.eu> 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?

No, I think it was intended to be 6 text characters.  My recollection
is that the older "scientific" machines didn't do BCD.  Certainly the
older UNIVAC 1100s and 490s didn't.

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

Most machines of the day used a 6 bit character encoding.  You're
right with Fieldata, but I don't know if it's still used.  Are the
1100s still in use?  They date back 60 years.

My guesswork from here on:

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

That would be extremely inefficient on such a small machine.  This was
ASCII, right?  I'd guess that the PDP-7, like the PDP-8, was intended
to use 6 bit characters, and that was probably the reason why it was
18 bits rather than 16 bits.

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

I was going to say "C doesn't talk about bytes", but I was wrong.  But
from K&R, 1st edition, page 126:

  The size is given in unspecified units called "bytes," which are the
  same size as a char.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200519/5272133e/attachment.sig>


      parent reply	other threads:[~2020-05-19  4:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200515213138.8E0F72D2D71E@macaroni.inf.ed.ac.uk>
     [not found] ` <alpine.DEB.2.21.2005151752250.19733@sd-119843.dedibox.fr>
     [not found]   ` <077a01d62b08$e696bee0$b3c43ca0$@ronnatalie.com>
     [not found]     ` <20200515233427.31Vab%steffen@sdaoden.eu>
     [not found]       ` <5DB09C5A-F5DA-4375-AAA5-0711FC6FB1D9@ronnatalie.com>
     [not found]         ` <20200516232607.nLiIx%steffen@sdaoden.eu>
     [not found]           ` <CABH=_VSqRFD6aHiRRdpQc7fzLaAcBXR-OMRJW3LqnqAih-W8EQ@mail.gmail.com>
2020-05-18 16:11             ` [COFF] [TUHS] v7 K&R C crossd
2020-05-18 16:30               ` clemc
2020-05-18 21:18               ` ron
2020-05-19  4:00               ` grog [this message]

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=20200519040008.GK1670@eureka.lemis.com \
    --to=coff@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).