<div dir="ltr"><div dir="ltr">On Sun, May 17, 2020 at 12:24 PM Paul Winalski <<a href="mailto:paul.winalski@gmail.com">paul.winalski@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/16/20, Steffen Nurpmeso <<a href="mailto:steffen@sdaoden.eu" target="_blank">steffen@sdaoden.eu</a>> wrote:<br>
><br>
> Why was there no byte or "mem" type?<br>
<br>
These days machine architecture has settled on the 8-bit byte as the<br>
unit for addressing, but it wasn't always the case.  The PDP-10<br>
addressed memory in 36-bit units.  The character manipulating<br>
instructions could deal with a variety of different byte lengths:  you<br>
could store six 6-bit BCD characters per machine word,</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I feel like this might be drifting into COFF territory now; Cc'ing there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">or five ASCII<br>
7-bit characters (with a bit left over), or four 8-bit characters<br>
(ASCII plus parity, with four bits left over), or four 9-bit<br>
characters.<br>
<br>
Regarding a "mem" type, take a look at BLISS.  The only data type that<br>
language has is the machine word.<br>
<br>
>   +getfield(buf)<br>
>   +char buf[];<br>
>   +{<br>
>   +       int j;<br>
>   +       char c;<br>
>   +<br>
>   +       j = 0;<br>
>   +       while((c = buf[j] = getc(iobuf)) >= 0)<br>
>   +       if(c==':' || c=='\n') {<br>
>   +               buf[j] =0;<br>
>   +               return(1);<br>
>   +       } else<br>
>   +               j++;<br>
>   +       return(0);<br>
>   +}<br>
><br>
> so here the EOF was different and char was signed 7-bit it seems.<br>
<br>
That makes perfect sense if you're dealing with ASCII, which is a<br>
7-bit character set.</blockquote><div><br></div><div>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.</div><div><br></div><div>        - Dan C.</div><div><br></div></div></div>