On: raising the semantic level of a program

Chuck Guzis cclist at sydex.com
Mon Jun 29 20:01:15 CDT 2020

On 6/29/20 12:41 PM, Rich Alderson via cctalk wrote:
> From: Chuck Guzis 
> Sent: Sunday, June 28, 2020 4:51 PM
>> It's noteworthy that on the Univac 1100 series, a "byte" could be 6, 9
>> or 12 bits, but not 8. (36 bit words).  The PDP-10 had similar issues,
>> such as the "packed" string format of 5 7-bit characters per word, with
>> one bit unused.
> Of course, on the PDP-10, bytes can be anywhere from 1 to 36 bits long;
> the size is defined in the pointer, not the hardware.
> And in the 7-bit ASCII text format, bit 35 (the word is big-endian) *is*
> used by the default editor:  In order to allow line numbering in source
> files for languages which do not allow it, the line numbers are ASCII
> strings with bit 35 set, and the monitor (=kernel=operating system) strips
> them out before handing them to compilers' input streams.

My point being that implicit "byte" addressability isn't essential if
there are no instructions that can take advantage of it.  The PDP-10
does have halfword instructions and although they're called "byte"
instructions, are what I'd call "bit field" instructions (LDB, DPB,
etc.)--but nothing that would implicitly be called a "byte".

Whereas, on say, S/360, an 8-bit byte is intrinsic to the hardware and
so defines addressing granularity.

Character sets on other systems can be wildly variable; consider WPS-8,
for example.

You do what works--and the lack of byte granularity is no particular


More information about the cctalk mailing list