Byte addressing was invented by IBM for the System/360, introduced in
1964. At least as I understand it. Up to that time, and indeed for a long
time after, machines had a “word length” which was the smallest
addressable unit of memory. This could have a range of sizes, e.g.

12 -- DEC PDP-5/8
18 -- DEC PDP-1/4/7/9
36 -- DEC PDP-6/10
60 -- CDC 6000-series
64 -- Cray

I’m sure there were also 24- and 48-bit machines. Note the popularity of
numbers with a range of different integer divisors, including powers of
both 2 and 3. The byte-addressable machines chucked away everything other
than powers of 2, which was a step backwards in this respect. ;)

(Interesting that the microprocessor world made byte addressing--and ASCII
character encoding--universal right from the beginning. Starting from a
clean slate, I guess.)

Why was byte addressing invented? I think it was for easy handling of
strings and other binary data. But why stop there? I guess the idea of
going all the way down to bit-level addressing was considered a bit
extreme? Certainly if you only had 32 (or, on those early IBMs, 24)
address bits, then using 3 of them to address within a byte would have
substantially cut down the available size of your address space.

I think the move to 64-bit architectures missed a trick, though: it could
have introduced bit-level addressing at the same time, given that we still
have plenty of address bits to spare. That would simplify bit-field
manipulations, too.

One side-effect of byte addressing has been the “endian wars”: the
inconsistency, between different machine architectures, of how to order
the bytes making up multibyte objects, particularly numbers. Big-endian
supposedly had the advantage of making memory dumps easier to read, but
little-endian always made more logical sense.

Nowadays, all the common CPU architectures are at least available in
little-endian form, if not exclusively so. But we still have legacy
oddities, like the TCP/IP network stack where integer fields are laid out
in big-endian ordering.

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>Byte addressing was invented by IBM for the System/360, introduced in
>1964. At least as I understand it. Up to that time, and indeed for a long
>time after, machines had a “word length” which was the smallest
>addressable unit of memory. This could have a range of sizes, e.g.
>
> 12 -- DEC PDP-5/8
> 18 -- DEC PDP-1/4/7/9
> 36 -- DEC PDP-6/10
> 60 -- CDC 6000-series
> 64 -- Cray

Commercial machines were character or digit addressed, as was at least
one scientfic computer, the IBM 1620.

The IBM 650 had 10 digit words, with characters stored as digit pairs.
The 702 and 705 were decimal character addressable. Instructions were
5 characters but data could be arbitrary length and location. The very
popular 1401 was also character addressed with variable length data.

>Why was byte addressing invented? I think it was for easy handling of
>strings and other binary data. But why stop there?

It was to be reasonably efficient both for character business data and
word scientific data. Since the words had to be aligned, it was easy
to handle them as a single unit in parallel on machines with internal
data paths wider than 8 bits, all the models bigger than 360/30.

> I guess the idea of
>going all the way down to bit-level addressing was considered a bit
>extreme?

STRETCH had bit addressing. It added a great deal of complication for
very little benefit. In the relatively rare situations where you want
to handle bit fields, shifting and masking is good enough without
slowing everything else down.

>One side-effect of byte addressing has been the “endian wars”: the
>inconsistency, between different machine architectures, ...

Until the PDP-11, all byte addressed machines were bigendian. Despite
a lot of looking, I have never found an explanation of why DEC made
the PDP-11 littlendian. I'm reasonably sure they were aware that it
was reversed from the 360, but they never said why.

Please do me a favor and DO NOT guess why they did it -- we have
already had lots and lots of guesses and we have no way to tell
whether any of the guesses are right.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Lawrence D'Oliveiro wrote:

> Byte addressing was invented by IBM for the System/360, introduced in
> 1964. At least as I understand it. Up to that time, and indeed for a long
> time after, machines had a “word length” which was the smallest
> addressable unit of memory. This could have a range of sizes, e.g.

> 12 -- DEC PDP-5/8
> 18 -- DEC PDP-1/4/7/9
> 36 -- DEC PDP-6/10
> 60 -- CDC 6000-series
> 64 -- Cray

CDC had a number of machines with 12-bit times k words. k element {1,2,3,5}

> I’m sure there were also 24- and 48-bit machines. Note the popularity of
> numbers with a range of different integer divisors, including powers of
> both 2 and 3. The byte-addressable machines chucked away everything other
> than powers of 2, which was a step backwards in this respect. ;)

I would make the argument that 2^k was a step forward not backwards.
Perhaps another day...

> (Interesting that the microprocessor world made byte addressing--and ASCII
> character encoding--universal right from the beginning. Starting from a
> clean slate, I guess.)

4004 anyone ?!?

> Why was byte addressing invented? I think it was for easy handling of
> strings and other binary data. But why stop there? I guess the idea of
> going all the way down to bit-level addressing was considered a bit
> extreme?

It was certainly a reason Intel's 432 died. {but there were lots}

> Certainly if you only had 32 (or, on those early IBMs, 24)
> address bits, then using 3 of them to address within a byte would have
> substantially cut down the available size of your address space.

> I think the move to 64-bit architectures missed a trick, though: it could
> have introduced bit-level addressing at the same time, given that we still
> have plenty of address bits to spare. That would simplify bit-field
> manipulations, too.

I don't see what is wrong with loading a container with the field and
then extracting or inserting into the container. You loose atomicity
but avoid doubling the number of LD/ST instructions.

> One side-effect of byte addressing has been the “endian wars”: the
> inconsistency, between different machine architectures, of how to order
> the bytes making up multibyte objects, particularly numbers. Big-endian
> supposedly had the advantage of making memory dumps easier to read, but
> little-endian always made more logical sense.

BE means you can read the strings in a core dump
LE means the bytes arrive in the order for on-line arithmetic
LE allows one to make 8-bit wide data paths and still implement a full
width architecture {but then so did 360/30)

> Nowadays, all the common CPU architectures are at least available in
> little-endian form, if not exclusively so. But we still have legacy
> oddities, like the TCP/IP network stack where integer fields are laid out
> in big-endian ordering.

I have a BITR instruction that rearranges BE<->LE for these reasons.

On Wed, 1 May 2024 01:49:56 -0000 (UTC), John Levine wrote:

> Until the PDP-11, all byte addressed machines were bigendian. Despite a
> lot of looking, I have never found an explanation of why DEC made the
> PDP-11 littlendian.

As I previously mentioned, little-endian just makes more sense.

Unfortunately, when their Fortran compiler implemented 32-bit integers (in
software), they got the words the wrong way round.

The VAX was like a 32-bit extension of the PDP-11, and it was consistently
little-endian everywhere.

On Wed, 1 May 2024 03:02:07 +0000, MitchAlsup1 wrote:

> I don't see what is wrong with loading a container with the field and
> then extracting or inserting into the container.

You still need a place to put a bit offset for the base address of the
field. Why not put it together with the rest of the address?

> BE means you can read the strings in a core dump
> LE means the bytes arrive in the order for on-line arithmetic
> LE allows one to make 8-bit wide data paths and still implement a full
> width architecture {but then so did 360/30)

The way I think of it is: consider how you specify these 3 conventions:
* numbering of bits within a byte
* numbering of bytes within a multibyte quantity
* the place values of bits in an integer

The only way to get all 3 consistent is with a little-endian architecture.
Every big-endian architecture has inconsistencies between these somewhere
or another.

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

> (Interesting that the microprocessor world made byte addressing--and ASCII
> character encoding--universal right from the beginning. Starting from a
> clean slate, I guess.)

A major market for microprocessors were pocket calculators,
cash registers and the like, which is why having 8 bits and BCD
arithmetic was an advantage - see the DAA instruction of the 8080
or the decimal flag on the 6502.

The basis of the 8008, the first serious microprocessor,
was the Datapoint 2200. A nice history can be found at
http://www.righto.com/2023/08/datapoint-to-8086.html .
And as the Datapoint 2200 was originally a "smart terminal",
it had to be able to connect to mainframes, which meant that
8-bit bytes were a natural choice. (And I still think that
having BCD influenced the decision to go to the 8-bit byte
on the /360).

So, anything but a clean slate.

On Wed, 1 May 2024 07:43:52 -0000 (UTC), Thomas Koenig wrote:

> And as the Datapoint 2200 was originally a "smart terminal",
> it had to be able to connect to mainframes, which meant that 8-bit bytes
> were a natural choice.

You mean IBM mainframes? I don’t think any other mainframes were byte-
addressable.

John Levine <johnl@taugh.com> writes:
>Until the PDP-11, all byte addressed machines were bigendian. Despite
>a lot of looking, I have never found an explanation of why DEC made
>the PDP-11 littlendian. I'm reasonably sure they were aware that it
>was reversed from the 360, but they never said why.
>
>Please do me a favor and DO NOT guess why they did it -- we have
>already had lots and lots of guesses and we have no way to tell
>whether any of the guesses are right.

Another case was the 6800 (big-endian) and its offspring, the 6502
(little-endian). In this case we know: little-endian is cheaper to
implement on an 8-bit processor.

Concerning the speculations about the PDP-11, here's one: Was it
designed for also supporting an implementation with a 4-bit or 8-bit
basis? The competing Nova was at first implemented with a 4-bit basis
(but it is word-addressed, so this is not visible in the byte order).
The PDP-X (the DEC-internal project that was canceled in favor of the
PDP-11 and eventually became the Nova) might have influenced the
PDP-11 in that way.

The other interesting question in this context is why the Datapoint
2200 (which is the basis of the Intel 8008 architecture) went for
little-endian. <https://en.wikipedia.org/wiki/Datapoint_2200> says:

|Because the original Datapoint 2200 had a serial processor, it needed
|to start with the lowest bit of the lowest byte in order to handle
|carries.

So it's the same reason as for the 6502.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
> On Wed, 1 May 2024 07:43:52 -0000 (UTC), Thomas Koenig wrote:
>
>> And as the Datapoint 2200 was originally a "smart terminal",
>> it had to be able to connect to mainframes, which meant that 8-bit bytes
>> were a natural choice.
>
> You mean IBM mainframes?

And compatibles. Together, they accounted for almost all mainframes.

>I don’t think any other mainframes were byte-
> addressable.

IBM set the minimum standard for character capabilities, a
terminal had to support eight bits or be laughed out of the market.
Adressability has little to do with it.

Hmm... what sort of terminals and character sets did people use on
a PDP-10? 7-bit ASCII? It (and the PDP-6) were released before
the ASCII standard came out. (And /360 was supposed to support
ASCII originally, but that bit in the PSW got dropped for the /370,
I believe).

On Wed, 1 May 2024 00:09:28 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>
> (Interesting that the microprocessor world made byte addressing--and
> ASCII character encoding--universal right from the beginning.
> Starting from a clean slate, I guess.)
>

It depends on what you call "microprocessor".
Majority of early Digital Signal Processors were word-addressable. Some
of them are still produced in significant quantities.
Two of those (TI TMS320C30 and ADI ADSP 21xx series) played major role
in my professional programming education.

Few word-addressable Digital Signal Processors had non-power-of-two
words. Motorola 24-bit 56K series was probably the most popular of
those, but there were others as well.

Microchip's PIC micro-controllers are word-addressable with quite
varying word width. According to Wikipedia, they are descendants of
General Instrument CP1600 CPU. I suppose, that their ancestor was
word-addressable as well.

In the world of general-purpose microprocessor, DEC Alpha (until EV6)
was more like word-addressable than byte-addressable, although it is a
matter of point of view.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>Byte addressing was invented by IBM for the System/360, introduced in
>1964. At least as I understand it. Up to that time, and indeed for a long
>time after, machines had a “word length” which was the smallest
>addressable unit of memory. This could have a range of sizes, e.g.
>
> 12 -- DEC PDP-5/8
> 18 -- DEC PDP-1/4/7/9
> 36 -- DEC PDP-6/10
> 60 -- CDC 6000-series
> 64 -- Cray

What about the IBM 1401, Electrodata 220 or Burroughs B5000?

>> I guess the idea of going all the way down to bit-level addressing
>>was considered a bit extreme?
>
> STRETCH had bit addressing. It added a great deal of complication for
> very little benefit. In the relatively rare situations where you want
> to handle bit fields, shifting and masking is good enough without
> slowing everything else down.

Bit addressing doesn't have to be expensive: the DEC Alpha could have
decided to use bit-addressing simply by ignoring/trapping more of the
lowest bits than it did.
Bit-addressing doesn't necessarily mean you can LD/ST at bit-granularity.

Stefan

Lawrence D'Oliveiro wrote:

> On Wed, 1 May 2024 03:02:07 +0000, MitchAlsup1 wrote:

>> I don't see what is wrong with loading a container with the field and
>> then extracting or inserting into the container.

> You still need a place to put a bit offset for the base address of the
> field. Why not put it together with the rest of the address?

Given a 20-40 year life of an architecture and the desire not to be limited
by addressability; I wanted and demanded of myself a full 63-bit virtual
address space per thread. Therefore, no bits in the pointer are available
for bit level addressing.

>> BE means you can read the strings in a core dump
>> LE means the bytes arrive in the order for on-line arithmetic
>> LE allows one to make 8-bit wide data paths and still implement a full
>> width architecture {but then so did 360/30)

> The way I think of it is: consider how you specify these 3 conventions:
> * numbering of bits within a byte
> * numbering of bytes within a multibyte quantity
> * the place values of bits in an integer

> The only way to get all 3 consistent is with a little-endian architecture.
> Every big-endian architecture has inconsistencies between these somewhere
> or another.

Very many LE machines got one or more of those wrong, too.

Thomas Koenig wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

>> (Interesting that the microprocessor world made byte addressing--and ASCII
>> character encoding--universal right from the beginning. Starting from a
>> clean slate, I guess.)

> A major market for microprocessors were pocket calculators,
> cash registers and the like, which is why having 8 bits and BCD
> arithmetic was an advantage - see the DAA instruction of the 8080
> or the decimal flag on the 6502.

From 1978-1980 I worked at NCR corporation on cash registers.
We made a BASIC interpreter as the programmable backbone of
the cash register lineup. Not a single decimal arithmetic
instruction was used in the cash register application. The
BASIC interpreter was written by a 5-man team in 8085 assembler.

That model was sold from 1979 through 1998. So the lack of
decimal arithmetic was not a significant disadvantage.

> The basis of the 8008, the first serious microprocessor,
> was the Datapoint 2200. A nice history can be found at
> http://www.righto.com/2023/08/datapoint-to-8086.html .
> And as the Datapoint 2200 was originally a "smart terminal",
> it had to be able to connect to mainframes, which meant that
> 8-bit bytes were a natural choice. (And I still think that
> having BCD influenced the decision to go to the 8-bit byte
> on the /360).

> So, anything but a clean slate.

Thomas Koenig wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>> On Wed, 1 May 2024 07:43:52 -0000 (UTC), Thomas Koenig wrote:
>>
>>> And as the Datapoint 2200 was originally a "smart terminal",
>>> it had to be able to connect to mainframes, which meant that 8-bit bytes
>>> were a natural choice.
>>
>> You mean IBM mainframes?

> And compatibles. Together, they accounted for almost all mainframes.

>>I don’t think any other mainframes were byte-
>> addressable.

> IBM set the minimum standard for character capabilities, a
> terminal had to support eight bits or be laughed out of the market.
> Adressability has little to do with it.

> Hmm... what sort of terminals and character sets did people use on
> a PDP-10? 7-bit ASCII? It (and the PDP-6) were released before
> the ASCII standard came out. (And /360 was supposed to support
> ASCII originally, but that bit in the PSW got dropped for the /370,
> I believe).

PDP 10 had a 6-bit "field data" character set and a 9-bit bigger than
ASCII character set. Programming languages and editors tended to use
the 6-bit character set.

mitchalsup@aol.com (MitchAlsup1) writes:
>Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>>> On Wed, 1 May 2024 07:43:52 -0000 (UTC), Thomas Koenig wrote:
>>>
>>>> And as the Datapoint 2200 was originally a "smart terminal",
>>>> it had to be able to connect to mainframes, which meant that 8-bit bytes
>>>> were a natural choice.
>>>
>>> You mean IBM mainframes?
>
>> And compatibles. Together, they accounted for almost all mainframes.
>
>>>I don’t think any other mainframes were byte-
>>> addressable.
>
>> IBM set the minimum standard for character capabilities, a
>> terminal had to support eight bits or be laughed out of the market.
>> Adressability has little to do with it.
>
>> Hmm... what sort of terminals and character sets did people use on
>> a PDP-10? 7-bit ASCII? It (and the PDP-6) were released before
>> the ASCII standard came out. (And /360 was supposed to support
>> ASCII originally, but that bit in the PSW got dropped for the /370,
>> I believe).
>
>PDP 10 had a 6-bit "field data" character set and a 9-bit bigger than
>ASCII character set. Programming languages and editors tended to use
>the 6-bit character set.

Early Burroughs systems used 6-bit binary "characters". Two fit
in one column of a 12-row Hollerith card.

>>Please do me a favor and DO NOT guess why they did it --

>Concerning the speculations about the PDP-11, here's one: Was it
>designed for also supporting an implementation with a 4-bit or 8-bit
>basis?

There are a bunch of design notes at bitsavers and none of them say
anything about it. There was one place that might have hinted that
little endian would save a few flip flops but since every PDP-11 was
16 bits internally, it wouldn't have saved much.

>The PDP-X (the DEC-internal project that was canceled in favor of the
>PDP-11 and eventually became the Nova) might have influenced the
>PDP-11 in that way.

I gather the PDP-X and PDP-11 were warring camps. There's a bunch
of PDP-X notes at bitsavers and I don't see anything related to
the -11. In the Bell et al book there's a lot about the -11 which
only says it's different from the -8 and -9 series.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>On Wed, 1 May 2024 01:49:56 -0000 (UTC), John Levine wrote:
>
>> Until the PDP-11, all byte addressed machines were bigendian. Despite a
>> lot of looking, I have never found an explanation of why DEC made the
>> PDP-11 littlendian.
>
>As I previously mentioned, little-endian just makes more sense.

Ahem. You're guessing.

I can assure you it didn't make more sense to all the people who read
360 core dumps. BTDT.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>> I guess the idea of going all the way down to bit-level addressing
>>>was considered a bit extreme?
>>
>> STRETCH had bit addressing. It added a great deal of complication for
>> very little benefit. In the relatively rare situations where you want
>> to handle bit fields, shifting and masking is good enough without
>> slowing everything else down.
>
>Bit addressing doesn't have to be expensive: the DEC Alpha could have
>decided to use bit-addressing simply by ignoring/trapping more of the
>lowest bits than it did.

That would waste three bits in every address, which would have been
phenomenally expensive in the 1960s when every byte cost real money.

The 360 had 12 bit displacements, so you could address a 4K range
without having to load another base register. This would shrink
it to 1K, so as a first approximation you'd need four times as
many base register loads. Nope.

I agree that with 64 bit addresses and memory that is pennies per
megabyte the tradeoffs are different but that horse left the barn 50
years ago. And I still don't think that bit operations are common
enough to be worth using bits in every non-bit address.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Thomas Koenig <tkoenig@netcologne.de>:
>8-bit bytes were a natural choice. (And I still think that
>having BCD influenced the decision to go to the 8-bit byte
>on the /360).

You don't have to guess. They explained in the IBM SJ paper
why they chose 8 bits rather than 6. BCD was part of it, as
was a belief that 6 bits wasn't going to be enough for
text, and it allowed 16 bit instructions and 32/64 bit
floating point.

Read it here: https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBM360-Amdahl_april64.pdf

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> schrieb:

> I gather the PDP-X and PDP-11 were warring camps. There's a bunch
> of PDP-X notes at bitsavers and I don't see anything related to
> the -11. In the Bell et al book there's a lot about the -11 which
> only says it's different from the -8 and -9 series.

Edson deCastro designed the PDP-X. When that project was cancelled
because of perceived potential competition with the 12-bit and
18-bit lines, he went off to found Data General and there built
the Nova, which used "byte pointers" where the uppermost bit
selected the low or high 8 bits of the 16-bit word.

Apparently, the PDP-11 was originally an 8-bit "desk calculator"
project which was then developed into the 16-bit architecture.
I have also read somewhere that competition from the Nova played
a major role.

DeCastro leaving was a major sore point for a lot of people at DEC,
so they probably did not tend to mention this influence.

There were allegations that the Nova was a copy of the proposed
PDP-X, but that was debunked now that some PDP-X development
documents have surfaced.

John Levine <johnl@taugh.com> writes:
>According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>>On Wed, 1 May 2024 01:49:56 -0000 (UTC), John Levine wrote:
>>
>>> Until the PDP-11, all byte addressed machines were bigendian. Despite a
>>> lot of looking, I have never found an explanation of why DEC made the
>>> PDP-11 littlendian.
>>
>>As I previously mentioned, little-endian just makes more sense.
>
>Ahem. You're guessing.
>
>I can assure you it didn't make more sense to all the people who read
>360 core dumps. BTDT.

To be fair, the tool that formatted the core dump could easily have
arranged the human visible values appropriately, much like xxd(1)
on linux does for little-endian values (i.e. when grouped with
four bytes per (32-bits), the byte 3 value is printed first).

> I agree that with 64 bit addresses and memory that is pennies per
> megabyte the tradeoffs are different but that horse left the barn 50
> years ago. And I still don't think that bit operations are common
> enough to be worth using bits in every non-bit address.

Historically, the advantages vs disadvantages have indeed been rather
against bit-addressing. AFAICT when the DEC Alpha came out was the most
favorable time: the first time that the cost was low enough (they
already had byte-addressing without byte-granularity of accesses,
they had plenty of address bits to waste, and there wasn't too much
existing 64bit code to break) to make the idea palatable.

Practical benefits are fairly limited, but it would just be The Right
thing to do, making it "easy" to eliminate some arbitrary restrictions
in languages like C such as the inability to take the address of
a struct's bitsized field. It would also have given an extra 3 bits to
play with for tagging purposes :-)

Stefan

>Thomas Koenig wrote:
>> Hmm... what sort of terminals and character sets did people use on
>> a PDP-10? 7-bit ASCII? It (and the PDP-6) were released before
>> the ASCII standard came out.

On the PDP-6 and PDP-10s I used they were all Teletypes and tty
compatible ASCII video terminals.

The normal way to store text was five 7-bit ASCII characters in a 36
bit word, since the byte handling instructiond made that easy to
handle. It was common to start each line on a word boundary, so you had
to skip zero padding bytes. Text editors often included line numbers
that were five digit characters aligned on a word boundary, followed
by a tab. The low bit in the word with the digits was set to say it's
a line number, and compilers knew to look for the bit and skip the
line number and tab.

Disk and DECtape used a six bit upper case ASCII subset for file names
so they could fit a six character name into one word. Compiler and
object file symbol tables used RADIX50 aka SQUOZE that fit a six
character symbol from a 40 character (octal 50) set into 32 bits with
four flag bits left.

> (And /360 was supposed to support
>> ASCII originally, but that bit in the PSW got dropped for the /370,
>> I believe).

They used a mutant ASCII that expanded from 7 to 8 bits by copying the
high bit into the middle of the byte, which nobody ever used. It was
one of the few inexplicably stupid choices in the 360.

According to MitchAlsup1 <mitchalsup@aol.com>:
>PDP 10 had a 6-bit "field data" character set and a 9-bit bigger than
>ASCII character set.

Dunno what computer that was, but it wasn't a PDP-10. Univac or GE600 maybe?
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wed, 01 May 2024 14:33:16 -0400, Stefan Monnier wrote:

>> I agree that with 64 bit addresses and memory that is pennies per
>> megabyte the tradeoffs are different but that horse left the barn 50
>> years ago. And I still don't think that bit operations are common
>> enough to be worth using bits in every non-bit address.
>
> Historically, the advantages vs disadvantages have indeed been rather
> against bit-addressing. AFAICT when the DEC Alpha came out was the most
> favorable time: the first time that the cost was low enough (they
> already had byte-addressing without byte-granularity of accesses,
> they had plenty of address bits to waste, and there wasn't too much
> existing 64bit code to break) to make the idea palatable.
>
> Practical benefits are fairly limited, but it would just be The Right
> thing to do, making it "easy" to eliminate some arbitrary restrictions
> in languages like C such as the inability to take the address of a
> struct's bitsized field. It would also have given an extra 3 bits to
> play with for tagging purposes :-)

The TMS340[12]0 were bit-addressed 32 bit processors.

<https://en.wikipedia.org/wiki/TMS34010>

I never programmed one in C but the addressing worked well for doing
graphics operations.