From Newsgroup: alt.folklore.computers

https://hackaday.com/2026/05/25/just-how-bad-was-the-intel-iapx432/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Peter Flass <Peter@Iron-Spring.com> writes:

https://hackaday.com/2026/05/25/just-how-bad-was-the-intel-iapx432/

432 group gave a talk at asilomar acm sigops meeting ... major problem I remember they talked about was putting sophisticated operating system
functions in silicon and problems/enhancements required new/replacement
chips.

I had recently done something similar for entry IBM 370 ... but it was microcode ... scheduling/dispatching for five CPU SMP, I/O drivers,
etc. ... so I could sympathize.
--
virtualization experience starting Jan1968, online at home since Mar1970
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

The ever-dependable RetroBytes channel did a post-mortem a few years
ago <https://www.youtube.com/watch?v=4o4MXV-d-jQ>.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 5/25/26 14:04, Lawrence DrCOOliveiro wrote:

The ever-dependable RetroBytes channel did a post-mortem a few years
ago <https://www.youtube.com/watch?v=4o4MXV-d-jQ>.

My favorite misfeature was using bit-addressing instead of byte
addressing. In one swell foop the segments could have been eight times
bigger, at the cost of a few bytes. I also assume it was harder to
decode the instructions, or at least used more logic that could have
been put to better use elsewhere.

Too bad the software for it doesn't exist, or didn't originally.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Mon, 25 May 2026 15:39:58 -0700, Peter Flass wrote:

My favorite misfeature was using bit-addressing instead of byte
addressing.

Now that 64-bit architectures are commonplace, I wonder why we canrCOt
have bit addressing instead of byte addressing. It would only cost
3 bits at the bottom of the address, and we have plenty to spare.

For performance, not every instruction would need to support
bit-aligned memory accesses -- regular loads/stores could either be
defined to demand those bits be zero, or to ignore them. You would
need special bit-aligned load/store instructions to take advantage of
them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 5/25/26 17:38, Lawrence DrCOOliveiro wrote:

On Mon, 25 May 2026 15:39:58 -0700, Peter Flass wrote:

My favorite misfeature was using bit-addressing instead of byte
addressing.

Now that 64-bit architectures are commonplace, I wonder why we canrCOt
have bit addressing instead of byte addressing. It would only cost
3 bits at the bottom of the address, and we have plenty to spare.

For performance, not every instruction would need to support
bit-aligned memory accesses -- regular loads/stores could either be
defined to demand those bits be zero, or to ignore them. You would
need special bit-aligned load/store instructions to take advantage of
them.

Like the Sigma 7. Load Byte, Load Halfword, and Load Word used Byte,
halfword, and word addressing respectively (IIRC).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Mon, 25 May 2026 15:39:58 -0700, Peter Flass wrote:

My favorite misfeature was using bit-addressing instead of byte addressing.

Now that 64-bit architectures are commonplace, I wonder why we can't have bit addressing instead of byte addressing. It would only cost 3 bits at the bottom of the address, and we have plenty to spare.

For performance, not every instruction would need to support bit-aligned memory accesses -- regular loads/stores could either be defined to demand those bits be zero, or to ignore them. You would need special bit-aligned load/store instructions to take advantage of them.

Congratulations.

You have just re-invented PDP-6 byte pointers.

From 1964.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Rich Alderson <news@alderson.users.panix.com> writes:

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Mon, 25 May 2026 15:39:58 -0700, Peter Flass wrote:

My favorite misfeature was using bit-addressing instead of byte addressing.

Now that 64-bit architectures are commonplace, I wonder why we can't have bit
addressing instead of byte addressing. It would only cost 3 bits at the
bottom of the address, and we have plenty to spare.

Plenty to spare? Not really. CXL and other technologies have made
even a 64-bit address space limiting.

Wasting three bits of the address for bit addressing, which outside
of specialized applications is not useful, would be silly.

For performance, not every instruction would need to support bit-aligned
memory accesses -- regular loads/stores could either be defined to demand
those bits be zero, or to ignore them. You would need special bit-aligned
load/store instructions to take advantage of them.

Congratulations.

You have just re-invented PDP-6 byte pointers.

From 1964.

Which proved to be an evolutionary dead-end.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 27 May 2026 18:59:52 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Plenty to spare? Not really. CXL and other technologies have made
even a 64-bit address space limiting.

...I'm mildly curious in which applications an address space of 16 EB
would be considered "limiting" o_O

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 5/27/26 11:59, Scott Lurndal wrote:

Rich Alderson <news@alderson.users.panix.com> writes:

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Mon, 25 May 2026 15:39:58 -0700, Peter Flass wrote:

My favorite misfeature was using bit-addressing instead of byte addressing.

Now that 64-bit architectures are commonplace, I wonder why we can't have bit
addressing instead of byte addressing. It would only cost 3 bits at the
bottom of the address, and we have plenty to spare.

Plenty to spare? Not really. CXL and other technologies have made
even a 64-bit address space limiting.

Wasting three bits of the address for bit addressing, which outside
of specialized applications is not useful, would be silly.

I'd be happy to see instructions that used bit pointers. In most cases
RISC is fine, but working with unaligned bit strings, for example
BITBLT, is just horrible. There's so much shifting and masking that
would be much more efficient at the hardware level.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 27 May 2026 13:06:31 -0700, Peter Flass wrote:

I'd be happy to see instructions that used bit pointers. In most
cases RISC is fine, but working with unaligned bit strings, for
example BITBLT, is just horrible. There's so much shifting and
masking that would be much more efficient at the hardware level.

I think thererCOs a feedback effect here: the C language (in which most
system software is written) makes it difficult to use unaligned
bitfields, particularly dynamic ones, so compilers have few
opportunities to generate those instructions. And CPU architecture
designers see that these instructions are not used much, and conclude
that theyrCOre not very important.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

John Ames <commodorejohn@gmail.com> writes:

On Wed, 27 May 2026 18:59:52 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Plenty to spare? Not really. CXL and other technologies have made
even a 64-bit address space limiting.

...I'm mildly curious in which applications an address space of 16 EB
would be considered "limiting" o_O

Question: Why are IPV6 addresses 128 bits?

Answer: A sparse address space is useful.

The address space addresses more than just DRAM (e.g. PCI devices),
and there are often alignment issues to be considered (e.g.
a hypervisor may align things on 1GB (30-bit) boundaries to reduce
TLB pressure for virtualization).

4TB uses 42 bits. A CXL system with 1024 4TB nodes uses 10 bits
for node Id.

That's only 12 left-over bits, and both memory and cluster size
can easily expand to consume those in the very near future.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Peter Flass <Peter@Iron-Spring.com> writes:

On 5/27/26 11:59, Scott Lurndal wrote:

Rich Alderson <news@alderson.users.panix.com> writes:

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Mon, 25 May 2026 15:39:58 -0700, Peter Flass wrote:

My favorite misfeature was using bit-addressing instead of byte addressing.

Now that 64-bit architectures are commonplace, I wonder why we can't have bit
addressing instead of byte addressing. It would only cost 3 bits at the >>>> bottom of the address, and we have plenty to spare.

Plenty to spare? Not really. CXL and other technologies have made
even a 64-bit address space limiting.

Wasting three bits of the address for bit addressing, which outside
of specialized applications is not useful, would be silly.

I'd be happy to see instructions that used bit pointers. In most cases
RISC is fine, but working with unaligned bit strings, for example
BITBLT, is just horrible. There's so much shifting and masking that
would be much more efficient at the hardware level.

That's a clear corner case. And not worth dealing with the PDP-6
style byte accesses.

For the most part, programmers abstract the operations:

template<class T> static inline T extract(T input, size_t stop_bit, size_t start_bit)
{
input >>= start_bit;
input &= maskT<T>(stop_bit - start_bit + 1);
return input;
}

uint64_t bits16_5 = bit::extract(value, 16, 5);

Pretty clear and let the compiler generate the appropriate
masking (or in many architectures bit-extract) instructions.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Peter Flass <Peter@Iron-Spring.com> wrote:

https://hackaday.com/2026/05/25/just-how-bad-was-the-intel-iapx432/

The benchmark result is the interesting part. The 432 beat an 8086
at the same clock speed doing the same algorithm in hand-written
code. That's not what you'd expect from a chip everyone agrees
was a disaster.

Mark's speculation that the problem was compiler optimization rather
than hardware design is worth taking seriously. The 432 had over 200
operators, built-in object-oriented programming, capability-based
addressing - all of which are nightmares for a compiler writer in
1981. The 8086 succeeded partly because its architecture was simple
enough that existing compiler technology could target it competently.

The pattern repeats with Itanium: a chip designed around the idea
that compilers could do instruction scheduling better than hardware,
which turned out to be true in theory and catastrophically wrong in
practice, because writing those compilers was harder than anyone
anticipated.

Both cases suggest that processor design has a social component.
It's not enough for hardware to be capable in principle. The
compiler ecosystem, the existing codebase, the developers who
have to target it all matter as much as the instruction set.
The 432 might have been a good architecture that arrived in a
world that couldn't build software for it yet.

Rich Alderson's point about PDP-6 byte pointers is apt too.
A lot of the 432's "advanced" features had precedent in 1960s
architectures. What was new was cramming all of them into one
chip at once.

Lev
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 5/30/26 00:13, Lev wrote:

Peter Flass <Peter@Iron-Spring.com> wrote:

https://hackaday.com/2026/05/25/just-how-bad-was-the-intel-iapx432/

The benchmark result is the interesting part. The 432 beat an 8086
at the same clock speed doing the same algorithm in hand-written
code. That's not what you'd expect from a chip everyone agrees
was a disaster.

Mark's speculation that the problem was compiler optimization rather
than hardware design is worth taking seriously. The 432 had over 200 operators, built-in object-oriented programming, capability-based
addressing - all of which are nightmares for a compiler writer in
1981. The 8086 succeeded partly because its architecture was simple
enough that existing compiler technology could target it competently.

This is the general consensus. [I think I have this right, but it's at
least approximately right] The Ada compiler originally put every
subroutine (whatever they're called in Ada, procedure, function?) into a separate segment, so there was a context switch on every call. Intel was working on it, and improved the performance a lot, but by that time the
damage was done.

The Multics people had a similar problem with the original Digitek
compiler. They had to throw it out and write a new one to get it working acceptably.

The pattern repeats with Itanium: a chip designed around the idea
that compilers could do instruction scheduling better than hardware,
which turned out to be true in theory and catastrophically wrong in
practice, because writing those compilers was harder than anyone
anticipated.

Both cases suggest that processor design has a social component.
It's not enough for hardware to be capable in principle. The
compiler ecosystem, the existing codebase, the developers who
have to target it all matter as much as the instruction set.
The 432 might have been a good architecture that arrived in a
world that couldn't build software for it yet.

This is an excellent point.

Rich Alderson's point about PDP-6 byte pointers is apt too.
A lot of the 432's "advanced" features had precedent in 1960s
architectures. What was new was cramming all of them into one
chip at once.

Lev

--- Synchronet 3.22a-Linux NewsLink 1.2