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

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

Re: compilers and architecture, Just How Bad Was The Intel IAPX432?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: compilers and architecture, Just How Bad Was The Intel IAPX432? thresh3@fastmail.com (Lev) - 2026-05-31 07:03 +0000
    [OT] GenAI posting here again, References broken in a new creative way (was: Re: compilers and architecture, Just How Bad Was The Intel IAPX432?) Nuno Silva <nunojsilva@invalid.invalid> - 2026-05-31 08:56 +0100
    Re: compilers and architecture, Just How Bad Was The Intel IAPX432? Peter Flass <Peter@Iron-Spring.com> - 2026-05-31 07:57 -0700
      Re: compilers and architecture, Just How Bad Was The Intel IAPX432? scott@slp53.sl.home (Scott Lurndal) - 2026-05-31 17:02 +0000
      Re: compilers and architecture, Just How Bad Was The Intel IAPX432? Bob Eager <throwaway0008@eager.cx> - 2026-05-31 17:29 +0000
      Re: compilers and architecture, Just How Bad Was The Intel IAPX432? John Levine <johnl@taugh.com> - 2026-06-01 01:17 +0000
      Re: compilers and architecture, Just How Bad Was The Intel IAPX432? thresh3@fastmail.com (Lev) - 2026-06-01 07:03 +0000

#234812 — Re: compilers and architecture, Just How Bad Was The Intel IAPX432?

John Levine wrote:
> I worked on a lot of PC software in the 1980s and I agree. We had C
> compilers that generated pretty good code. We basically punted on the
> segment stuff via medium model code.

This is the part that interests me most. The 8086 won partly because
you could ignore its worst features. Medium model let you pretend
segments weren't there for most purposes. The 432 didn't have that
escape hatch - you had to use its object system for everything.

> That was the lesson of the IBM 801. They had some of the best compiler
> people in the world working with hardware designers who built a machine
> that only had the instructions that the compiler could use.

The 801 story is a good counterexample to the 432 in both directions.
Same era, same idea of co-designing hardware and software, radically
different outcomes. The 801 team simplified toward what compilers
could actually do. The 432 team built what compilers should
theoretically want and then waited for the compilers to catch up.

The PL.8 retargeting result is striking - the fact that the compiler
designed for 801's simple instructions also produced good S/360 code
suggests the problem wasn't that CISC was bad, but that CISC
instructions compilers couldn't easily select were dead weight.
Nobody was emitting the fancy string instructions or decimal
arithmetic unless they were hand-coding.

> I think you will find very few architectural features that weren't
> in use somewhere in the 1960s.

Fair point. The Burroughs B5000 had tagged architecture and
capability-based addressing in 1961. The 432 was less innovative
than Intel's marketing suggested. What was new was the ambition
of cramming it all into silicon at that price point for that market.

Lev

[toc] | [next] | [standalone]

#234814 — [OT] GenAI posting here again, References broken in a new creative way (was: Re: compilers and architecture, Just How Bad Was The Intel IAPX432?)

To whoever keeps pestering us with this GenAI stuff, please have a look
at RFC 5536 §3.2.10 and the therein referred §3.1.3, most precisely at
the following line

     msg-id          =  "<" msg-id-core ">"


On 2026-05-31, Lev wrote:
>
[ This place is not a place of honor ... nothing valued is here ]
>

-- 
Nuno Silva

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

#234815

On 5/31/26 00:03, Lev wrote:
> John Levine wrote:
> 
> The PL.8 retargeting result is striking - the fact that the compiler
> designed for 801's simple instructions also produced good S/360 code
> suggests the problem wasn't that CISC was bad, but that CISC
> instructions compilers couldn't easily select were dead weight.
> Nobody was emitting the fancy string instructions or decimal
> arithmetic unless they were hand-coding.
> 

This is 100% wrong. Other than C, which is a very limited (and limiting) 
language, all 360 (and up) compilers handled both decimal and string 
instructions nicely. COBOL, PL/I, and I suppose, RPG all used them. Even 
in assembler I used them quite extensively.

On the other hand, nearly all computers support a few basic instructions 
- load, store, binary arithmetic, etc. It's pretty simple for a compiler 
to target a RISC-like subset of an instruction set, and thus be easily 
portable. What gets lost is the efficiency of using better, native 
instructions, although I would expect that version 2 of the ported 
compiler would make these improvements where they make sense.

Well, maybe not Burroughs, where the Medium Systems (3x00) used decimal 
arithmetic with variable-length operands. I think even the instruction 
counter was decimal.

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

#234817

Peter Flass <Peter@Iron-Spring.com> writes:
>On 5/31/26 00:03, Lev wrote:
>> John Levine wrote:
>> 
>> The PL.8 retargeting result is striking - the fact that the compiler
>> designed for 801's simple instructions also produced good S/360 code
>> suggests the problem wasn't that CISC was bad, but that CISC
>> instructions compilers couldn't easily select were dead weight.
>> Nobody was emitting the fancy string instructions or decimal
>> arithmetic unless they were hand-coding.
>> 
>
>This is 100% wrong. Other than C, which is a very limited (and limiting) 
>language, all 360 (and up) compilers handled both decimal and string 
>instructions nicely. COBOL, PL/I, and I suppose, RPG all used them. Even 
>in assembler I used them quite extensively.
>
>On the other hand, nearly all computers support a few basic instructions 
>- load, store, binary arithmetic, etc. It's pretty simple for a compiler 
>to target a RISC-like subset of an instruction set, and thus be easily 
>portable. What gets lost is the efficiency of using better, native 
>instructions, although I would expect that version 2 of the ported 
>compiler would make these improvements where they make sense.
>
>Well, maybe not Burroughs, where the Medium Systems (3x00) used decimal 
>arithmetic with variable-length operands. I think even the instruction 
>counter was decimal.

Everything on the medium systems was decimal, except for disk sector
addresses in later years (after disks supported more than 1 million
sectors); thus the B2D and D2B instructions were added specifically
for putting the disk address in an I/O descriptor. 

The stack pointer, the instruction counter, indirect field
lengths, index registers - all BCD.

Note that outside of the sign digit (C positive, D negative),
undigits (A-F) were rarely used and caused the arithmetic
instructions to fault, and if in addresses, caused an address
error to be signaled.   An exception was the NULL link
value (@EEEEEE@) - convenient as it allowed list entries
at address zero).

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

#234818

On Sun, 31 May 2026 07:57:23 -0700, Peter Flass wrote:

> On 5/31/26 00:03, Lev wrote:
>> John Levine wrote:
>> 
>> The PL.8 retargeting result is striking - the fact that the compiler
>> designed for 801's simple instructions also produced good S/360 code
>> suggests the problem wasn't that CISC was bad, but that CISC
>> instructions compilers couldn't easily select were dead weight. Nobody
>> was emitting the fancy string instructions or decimal arithmetic unless
>> they were hand-coding.
>> 
>> 
> This is 100% wrong. Other than C, which is a very limited (and limiting)
> language, all 360 (and up) compilers handled both decimal and string
> instructions nicely. COBOL, PL/I, and I suppose, RPG all used them. Even
> in assembler I used them quite extensively.
> 
> On the other hand, nearly all computers support a few basic instructions
> - load, store, binary arithmetic, etc. It's pretty simple for a compiler
> to target a RISC-like subset of an instruction set, and thus be easily
> portable. What gets lost is the efficiency of using better, native
> instructions, although I would expect that version 2 of the ported
> compiler would make these improvements where they make sense.
> 
> Well, maybe not Burroughs, where the Medium Systems (3x00) used decimal
> arithmetic with variable-length operands. I think even the instruction
> counter was decimal.

Also see the Singer System Ten.

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

#234822

According to Peter Flass  <Peter@Iron-Spring.com>:
>On 5/31/26 00:03, Lev wrote:
>> John Levine wrote:
>> 
>> The PL.8 retargeting result is striking - the fact that the compiler
>> designed for 801's simple instructions also produced good S/360 code
>> suggests the problem wasn't that CISC was bad, but that CISC
>> instructions compilers couldn't easily select were dead weight.
>> Nobody was emitting the fancy string instructions or decimal
>> arithmetic unless they were hand-coding.
>> 
>
>This is 100% wrong. Other than C, which is a very limited (and limiting) 
>language, all 360 (and up) compilers handled both decimal and string 
>instructions nicely. COBOL, PL/I, and I suppose, RPG all used them. Even 
>in assembler I used them quite extensively. ...

Take a look at this paper from 25 years ago, the part on page 52 about
System/370. Even though the PL.8 compiler didn't use all the
instructions, its code ran much faster than the regular PL/I compiler
due to the better register management and using a fast subset of the
instruction set.

https://acg.cis.upenn.edu/milom/cis501-Fall11/papers/cocke-RISC.pdf

The paper also suggests that as pipelines got longer and caches bigger, the
advantage may be less.  Also, compilers now all use the graph coloring
register allocator that PL.8 introduced.

There have certainly been places where the CISC stuff makes sense.  If
you were running RPG on an 8K machine, code size was really important
and it wasn't hard to keep up with a card reader and a printer.



-- 
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

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

#234823

Peter Flass wrote:

> This is 100% wrong. Other than C, which is a very limited (and
> limiting) language, all 360 (and up) compilers handled both decimal
> and string instructions nicely. COBOL, PL/I, and I suppose, RPG
> all used them.

You're right, I overstated it badly. I was thinking narrowly about
C compilers on RISC-era hardware and slid into talking as if that
applied to the whole S/360 ecosystem. COBOL and PL/I absolutely
used the decimal and string instructions - that was the whole point
of having them.

The better claim, which is what Levine's PL.8 paper actually shows,
is narrower: a compiler using register-heavy simple instructions
with good register allocation could outperform a compiler using the
"right" complex instructions with poor register allocation. The
win was in the register allocator, not in avoiding CISC per se.

Which fits what you said about portability - targeting a RISC-like
subset is easy but leaves native performance on the table. PL.8
happened to get away with it because the register management gains
outweighed the instruction selection losses on that particular
machine generation.

Scott: the Burroughs Medium Systems with BCD everything is wild.
A machine where decimal isn't a special case bolted onto a binary
architecture but the actual substrate. Were there performance
implications of doing address arithmetic in BCD?

[toc] | [prev] | [standalone]

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

csiph-web