Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #234795 > unrolled thread

Just How Bad Was The Intel IAPX432?

Back to article view | Back to alt.folklore.computers

Contents

  Just How Bad Was The Intel IAPX432? Peter Flass <Peter@Iron-Spring.com> - 2026-05-25 07:44 -0700
    Re: Just How Bad Was The Intel IAPX432? Lynn Wheeler <lynn@garlic.com> - 2026-05-25 07:54 -1000
    Re: Just How Bad Was The Intel IAPX432? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-25 21:04 +0000
      Re: Just How Bad Was The Intel IAPX432? Peter Flass <Peter@Iron-Spring.com> - 2026-05-25 15:39 -0700
        Re: Just How Bad Was The Intel IAPX432? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-26 00:38 +0000
          Re: Just How Bad Was The Intel IAPX432? Peter Flass <Peter@Iron-Spring.com> - 2026-05-25 20:41 -0700
          Re: Just How Bad Was The Intel IAPX432? Rich Alderson <news@alderson.users.panix.com> - 2026-05-26 16:16 -0400
            Re: Just How Bad Was The Intel IAPX432? scott@slp53.sl.home (Scott Lurndal) - 2026-05-27 18:59 +0000
              Re: Just How Bad Was The Intel IAPX432? John Ames <commodorejohn@gmail.com> - 2026-05-27 12:11 -0700
                Re: Just How Bad Was The Intel IAPX432? scott@slp53.sl.home (Scott Lurndal) - 2026-05-27 22:44 +0000
              Re: Just How Bad Was The Intel IAPX432? Peter Flass <Peter@Iron-Spring.com> - 2026-05-27 13:06 -0700
                Re: Just How Bad Was The Intel IAPX432? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-27 22:34 +0000
                Re: Just How Bad Was The Intel IAPX432? scott@slp53.sl.home (Scott Lurndal) - 2026-05-27 22:47 +0000

#234795 — Just How Bad Was The Intel IAPX432?

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

[toc] | [next] | [standalone]

#234796

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

[toc] | [prev] | [next] | [standalone]

#234797

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

[toc] | [prev] | [next] | [standalone]

#234798

On 5/25/26 14:04, Lawrence D’Oliveiro 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.

[toc] | [prev] | [next] | [standalone]

#234799

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.

[toc] | [prev] | [next] | [standalone]

#234800

On 5/25/26 17:38, Lawrence D’Oliveiro 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 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.

Like the Sigma 7. Load Byte, Load Halfword, and Load Word used Byte, 
halfword, and word addressing respectively (IIRC).

[toc] | [prev] | [next] | [standalone]

#234801

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

[toc] | [prev] | [next] | [standalone]

#234802

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.

[toc] | [prev] | [next] | [standalone]

#234803

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

[toc] | [prev] | [next] | [standalone]

#234806

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.

[toc] | [prev] | [next] | [standalone]

#234804

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.

[toc] | [prev] | [next] | [standalone]

#234805

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 there’s 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 they’re not very important.

[toc] | [prev] | [next] | [standalone]

#234807

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.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.folklore.computers

csiph-web