From: crossd at gmail.com (Dan Cross)
Subject: [COFF] [TUHS] v7 K&R C
Date: Mon, 18 May 2020 12:11:00 -0400 [thread overview]
Message-ID: <CAEoi9W6jwA1_MGD11Sc837YMgDfGJWzAQFCyrbrx72a1PJ3ViA@mail.gmail.com> (raw)
In-Reply-To: <CABH=_VSqRFD6aHiRRdpQc7fzLaAcBXR-OMRJW3LqnqAih-W8EQ@mail.gmail.com>
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? 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: <http://minnie.tuhs.org/pipermail/coff/attachments/20200518/4afbbf66/attachment.htm>
next parent reply other threads:[~2020-05-18 16:11 UTC|newest]
Thread overview: 6+ 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 ` 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] <CAKzdPgyYUCPDn3KjRgx6Aw_=AD8O2Mdk0WkmPZCH9oN+XkPebg@mail.gmail.com>
[not found] ` <20200511005745.GL17035@mcvoy.com>
[not found] ` <m1jYCHm-0036tPC@more.local>
[not found] ` <CABH=_VRucqOpJvZVRqhz6Bv-kVe6P-7Hk3SFDuO0XyKZ_=oCBg@mail.gmail.com>
[not found] ` <CAC20D2NTRE4cK5jewe-Yuo1UVnH6pY2u-wSt8NiG-5hBkzvvzQ@mail.gmail.com>
[not found] ` <CABH=_VT9dU7kuJSa+iN6zdF7RMpS-hE92DsyeSuMkTmrYGL_9g@mail.gmail.com>
[not found] ` <357EFE54-BD94-4C10-8C43-C6735BF7D317@via.net>
[not found] ` <20200511202555.GU17035@mcvoy.com>
[not found] ` <CABH=_VS8XO8BQA=fMCGTf8u-ubXLKT1tzUJ5ntTXWkjeGk1sSA@mail.gmail.com>
[not found] ` <alpine.BSF.2.21.9999.2005140930270.18677@aneurin.horsfall.org>
[not found] ` <20200514173206.GJ20771@mcvoy.com>
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:
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=CAEoi9W6jwA1_MGD11Sc837YMgDfGJWzAQFCyrbrx72a1PJ3ViA@mail.gmail.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).