From: Rich Alderson on
jmfbahciv(a) writes:

> In article <etbjul$b66$1(a)>, johnl(a) (John L) wrote:

>> Well, sure, you could keep running your old 18 bit programs, just like
>> on a 386 you can keep running your old 16 bit 286 programs. But if
>> you wanted to use the larger address space,


>> you had to rewrite your
>> programs, and since segmented address spaces sucked as badly then as
>> it does now, we didn't. Where I was (Yale) we moved to 4BSD on a Vax.

> I don't understand. Why did you have to change code to run on
> a -20 when the backplane was installed? There was nothing, other
> than your local requirements, that forced you to change code.

*This* is what I was talking about in previous posts: Not using a changed
architecture with an expanded instruction set, but using the old architecture
with expanded memory.

Let's say you have a CAD program that runs on the PDP-10. Call it SUDS, for
the sake of argument. The amount of work that can be done in an 18-bit space
is sufficient for some time, but eventually you need to do work on a board
larger than will fit into your system.

So you have to revise SUDS to use "extended addressing" and "non-zero sections"
so that your board representations can be held in memory. But this means that
you have to rewrite a lot of nonobvious parts of SUDS, because the architecture
only allows addressing of non-zero sections from non-zero sections, and in such
a section, where addresses are not 18 bits but 30, certain common instructions
do not work, for example AOBJN, the most common loop type.

(For those not familiar with the PDP-10, AOBJN _A_dds _O_ne to _B_oth halves of
the accumulator (AC) specified, and if the resulting value is _N_egative, it
_J_umps to the 18-bit address specified in the instruction. It is frequently
used to loop over table entries: The number of table entries, negated, is put
in the left half of the AC and the address of the first entry is put in the
right half, and the AC is used as an (18-bit) index register to reference the
table entries in the loop body. At the bottom of the loop, AOBJN AC,LUPTOP and
you're now pointing at the next entry at the top of the loop.

In extended sections, 30-bit addresses in ACs interfere with AOBJN, so all
loops of this kind have to be rewritten. A number of other gotchas of similar
stripe exist.)

And that's why some people left the PDP-10 behind, Barb.

Rich Alderson | /"\ ASCII ribbon |
news(a) | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
From: Rich Alderson on
John Ahlstrom <AhlstromJK(a)> writes:

> Rich Alderson wrote:
> -- snip snip

>> The index base can be 35 bits, if you like. (Not 36 because of the sign
>> bit, but that's still a 32GW address.) Unfortunately, the *instruction*
>> *format* does not give you more than 18 bits on top of whatever is in the
>> index AC. Being able to address more than that 18 bits' worth is the
>> concern, not "How big an address can I get out of the index register?"

>> *That's* where the address space is limited.

>> The VAX architecture, with its variable-length instructions, can address
>> both a source and a destination in a single instruction which are more than
>> 18 bits away from their respective indexes. (IIRC, they can go to 24 bits,
>> but they're addressing octets, not words.)

> -- snip snip

> IBM had been getting 2**24 bit memory and 24 bit addresses with 12 bit
> displacements in instructions since 1964 (announcement) or 1965 (delivery).
> Granted they had a base register as well as an index register in their
> effective address calculation, but that could always have been done in a
> previous instruction in a 10-like machine with 35-bit addresses and 18 bit
> displacements.

I learned the 360 in 1969, and made a living programming in Assembler F, PL/1,
and COBOL for several years before learning to program the PDP-10. I still
sometimes miss base vs. index registers, late at night.

My first major application on the DEC-20 (where I was the designer as well as
the coder) got written in Assembler F translated to Macro-20, because I needed
large data structures and thought simulating base/index addressing was the way
to get them. It looks easy; it's not. It gets really ugly really fast.

This is what I referred to as "schratzing around" in another post.

Rich Alderson | /"\ ASCII ribbon |
news(a) | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
From: Anne & Lynn Wheeler on
Peter Flass <Peter_Flass(a)> writes:
> Ironic. Someone, possibly you, mantioned that the AS/400 (iSeries)
> boxes were a scaled down version of what FS was supposed to be, and
> now they're running on top of RISC CPUs.

re: he Perfect Computer - 36 bits? he Perfect Computer - 36 bits?

the small business computer s/38 ... implemented some number of FS
features (as well as 48bit addressing):

there was some discussion that as part of fort knox ... the myriad of
corporate microprocessors would be moved to 801/risc (iliad); low-end
and mid-range 370s, s/38 followon and many others. in thread last fall,
iliad ran into all sorts of schedule problems ... a couple refs: To RISC or not to RISC To RISC or not to RISC

and rochester quickly did a cisc processor for as/400. later rochester
got involved with somerset/powerpc ... and finally did move to a
variety of that risc.

from above:

The AS/400 and its successors survive since their instruction set
(called TIMI for "Technology Independent Machine Interface" by IBM)
allows the operating system and application programs to take advantage
of advances in hardware and software without recompilation. TIMI is a
virtual instruction set; it is not the instruction set of the
underlying CPU. All user-mode programs are stored as TIMI
instructions, which means that it is not possible for them to use the
instruction set of the underlying CPU, thus ensuring hardware
independence. This is conceptually somewhat similar to the virtual
machine architecture of programming environments such as Smalltalk,
Java and .NET. The key difference is that it is embedded so deeply
into the AS/400's design as to make all applications and even the bulk
of its operating systems binary-compatible across different processor

... snip ..

misc. old email and other posts mentioning iliad and/or fort knox A Day For Surprises (Astounding Itanium Tricks) A Day For Surprises (Astounding Itanium Tricks) 32 or even 64 registers for x86-64? To RISC or not to RISC To RISC or not to RISC To RISC or not to RISC P390 Reasons for the big paradigm switch Ranking of non-IBM mainframe builders? What's a mainframe? "The Elements of Programming Style" Multiple mappings Multiple mappings V2X2 vs. Shark (SnapShot v. FlashCopy) Why so little parallelism? "The Elements of Programming Style"

other posts in this thread: The Perfect Computer - 36 bits? The Perfect Computer - 36 bits? The Perfect Computer - 36 bits? The Perfect Computer - 36 bits?
From: Quadibloc on
jmfbahciv(a) wrote:
> There were many sane ways to move customers from the one product
> line to the other, IF that was a goal. The choice was the most
> insane method. This was part of the IBM thinking that was
> injected (sorry, Lynn) into middle management. IBM customers
> were used to being ordered around "for their own good". DEC
> customers had always been severely allergic to this kind of
> treatment; this allergy was why they bought DEC instead
> of IBM in the first place.

I was not in any way directly involved or affected by this. When I
read about DEC's decision at the time, I did disapprove of it.

After all, people want to upgrade their computers in the most
effective way possible - and the most effective way is the one that
requires them to spend the least money converting their own programs
and data.

So if nobody makes PDP-10 computers any more, there's no particular
benefit to their owners doing their next upgrade with DEC - and a
motive not to do so, so as to punish this behavior.

Under what circumstances would abandoning their 10 and 20 customers be

DEC is smaller than IBM. The PDP-11 was their most popular
architecture, and it was in line with prevailing industry standards.
DEC had many competitors which were larger than it, and which had
fewer architectures.

So, they may have felt that they *could not* use their limited
engineering resources to support both lines of product. If they tried,
they would make the VAX non-competitive - and the successor to the
DECsystem-20 so laughable as to permanently impair the company's
reputation. Only by putting *all* the company's strength into making a
better VAX could DEC *hope* to survive!

Is that scenario obviously false?

Is DEC around today? Maybe that *isn't* because it kicked their loyal
DECsystem-20 customers in the face. Maybe it is because the market was
so competitive that even with their best efforts, the VAX and the
Alpha couldn't become big enough to be players.

Where is the SEL32? Where is Interdata? Does Honeywell still make
computers? (They did make a nice mouse a while back...)

Is AMD making PowerPC architecture chips, has it even considered
licensing the Itanium architecture from Intel, or the Alpha
architecture from Compaq, or the Sparc architecture from Sun?

So maybe DEC management may have been heartless and unfeeling. They
may have made the mistake of valuing a *future* for DEC which it
wasn't big enough to grasp anyways too much over the *present* of a
DECsystem-20 market that could bring in more cashflow for a little

But were they truly as irrational as they seem to you - or were they
acting as is standard practice today, as is inevitable in a brutally
competitive computer marketplace, where only the gigantic companies
have the resources to survive?

John Savard

From: Andrew Swallow on
Quadibloc wrote:

> Is AMD making PowerPC architecture chips, has it even considered
> licensing the Itanium architecture from Intel, or the Alpha
> architecture from Compaq, or the Sparc architecture from Sun?

However Intel, Freescale (Motorola)and Philips still make ARM chips.

Mostly for use in mobile phones in a handbag near you.

Andrew Swallow