System/360; Hardwired vs. Microcoded

jsa...@ecn.ab.ca

unread,

Apr 3, 2005, 5:36:25 PM4/3/05

to

In my recent reading and web searches, I have learned some interesting
and unexpected facts about the use of microcode with the IBM
System/360.

I knew that of the original 360 models, only the Model 75 was
hardwired, the rest being microcoded. And, I believe I have heard that
the Model 195, and, by extension, the Model 91 and 95, were also
hardwired.

But I was surprised to learn, recently, that the Model 85 used
microcode. According to the article I read that mentioned this, IBM
would have used microcode for the 75, but was forced to use hardwired
logic because they had no sufficiently fast read-only memory available.

But even more recently, I learned something even more startling. The
IBM System/360 Model 40 definitely was microprogrammed; a FE manual on
Al Kossow's site shows the microcode format for it.

But, according to the Functional Characteristics book for the Model 44,
it, too, had *hardwired* control logic. This let it run faster, but
meant that the decimal and character instructions were not available as
options for it.

John Savard

Eric Smith

unread,

Apr 3, 2005, 5:52:03 PM4/3/05

to

John Savard wrote:
> I have learned some interesting
> and unexpected facts about the use of microcode with the IBM
> System/360.

Hardwired: 360/44 360/75 360/91 360/95 360/195 370/195

All other 360 and 370 models are microcoded.

> But I was surprised to learn, recently, that the Model 85 used
> microcode.

It was later, so more advanced ROS (ROM) technology was available
for the control store.

The 360/85 was also the first model to use cache memory.

I suspect that the 360/85 microarchitecture became the basis for the
370/165, but I haven't read the CE manuals so I couldn't say with any
high degree of certainty.

> But even more recently, I learned something even more startling. The
> IBM System/360 Model 40 definitely was microprogrammed; a FE manual on
> Al Kossow's site shows the microcode format for it.
>
> But, according to the Functional Characteristics book for the Model 44,
> it, too, had *hardwired* control logic. This let it run faster, but
> meant that the decimal and character instructions were not available as
> options for it.

Contrary to what some people have claimed, there is almost no relation
between the 360/40 and 360/44 hardware designs. The 360/44 is a very
odd beast.

jsa...@ecn.ab.ca

unread,

Apr 3, 2005, 8:36:50 PM4/3/05

to

Eric Smith wrote:

> Contrary to what some people have claimed, there is almost no
relation
> between the 360/40 and 360/44 hardware designs. The 360/44 is a very
> odd beast.

Besides the size and price, they do have very similar-looking front
panels.

Given that the 360/40 is microcoded, and the 360/44 is hardwired, I
suppose they would have to be unrelated; but I would have expected that
as much as possible of the circuitry (which wouldn't have been much)
might have overlapped.

Interestingly enough, Pugh, Johnson, and Palmer doesn't even mention
the 360/44 in the index!

John Savard

Brian Inglis

unread,

Apr 3, 2005, 8:40:26 PM4/3/05

to

On 03 Apr 2005 14:52:03 -0700 in alt.folklore.computers, Eric Smith
<er...@brouhaha.com> wrote:

Presumably the 360/44 was either a process or scientific machine?

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply

jsa...@ecn.ab.ca

unread,

Apr 3, 2005, 8:42:34 PM4/3/05

to

jsav...@ecn.ab.ca wrote:

> Besides the size and price, they do have very similar-looking front
> panels.

I see from

http://www.thegalleryofoldiron.com/2044.HTM

that this is less true than I thought...

John Savard

jsa...@ecn.ab.ca

unread,

Apr 3, 2005, 8:44:43 PM4/3/05

to

Brian Inglis wrote:

> Presumably the 360/44 was either a process or scientific machine?

Yes, that is precisely true.

It had additional interrupt facilities, in addition to higher
performance floating-point than other computers in its range.

John Savard

Sam Drake

unread,

Apr 3, 2005, 10:00:37 PM4/3/05

to

When I was in school (late 70s) we used a 360/44, and I studied it
quite a bit. The 44 had transistorized registers, instead of registers
made from core memory as the other models did at the time. It was also
(mostly) hard-wired rather than microcoded.

The 44 didn't implement the entire 360 instruction set. The subset
implemented was oriented towards scientific computing; all of the 6
byte long instructions were unimplemented. These instructions included
decimal arithmetic and memory-to-memory moves. Bottom line was that it
was a super Fortran computer and a lousy COBOL computer.

I called the 44 "mostly" hardwired because it had hardware provisions
for running an "emulator" to implement te missing instructions. The
front console had the standard "Initial Program Load" (modern
translation: "boot") button, as well as a 44-specific "Emulator Load"
button. We had a magic card deck, kept in a locked drawer, that
contained the "Dublin Emulator" that completed te instruction set.
After any power down we had to boot the emulator, and then could boot
the OS.

I spent some time with the 44 Principles Of Operations manual. The
"emulator" ran in what was referred to as the "negative address space"
- with addresses < 0. Whenever an "illegal operation" error was about
to be flagged, due to an illegal opcode, rather than loading the
program new PSW as a 360 normally would it instead flipped to the
"negative address space" to give the emulator a chance at it. I only
vaguely remember any other details, but it was truly wacky.

...Sam

(Naturally, by the time I saw it, it was being used primarily by
undergraduate COBOL classes. AACK.)

Brian Inglis

unread,

Apr 4, 2005, 1:35:02 AM4/4/05

to

On 3 Apr 2005 17:42:34 -0700 in alt.folklore.computers,
jsa...@ecn.ab.ca wrote:

Great site for IBM mainframe history with pictures.

Rob Warnock

unread,

Apr 4, 2005, 5:44:48 AM4/4/05

to

<jsa...@ecn.ab.ca> wrote:
+---------------

+---------------

I worked in a university computing lab in the late 1960's, and when we
were replacing an IBM 1410 (which had been connected to some Adage A/D &
D/A converters) with a new machine the finalists were an SDS [or XDS]
Sigma 7, an Adage Ambilog 200, an IBM 360/44, and an RCA Spectra-70/55.
The 360/44 was being considered for its realtime capabilities and some
special interfacing hooks, but the Spectra-70 won out [and I had to build
a bus/tag channel adapter from it to our analog/hybrid gear -- anybody
remember the CATSUP signal?].

A few years later I was working in a different department, this time
replacing an IBM 1620, and the finalists were an IBM 360/44 and a DEC
PDP-10. The PDP-10 won [and became one of my all-time favorite machines!].

The useful weirdnesses of the 360/44 were just not enough in many cases
to overcome its lack of general competitiveness, I suspect.

-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Joe Morris

unread,

Apr 4, 2005, 8:50:59 AM4/4/05

to

jsa...@ecn.ab.ca writes:

>But even more recently, I learned something even more startling. The
>IBM System/360 Model 40 definitely was microprogrammed; a FE manual on
>Al Kossow's site shows the microcode format for it.

It's also worth noting that the microcode store on the /40 was the
same technology (TROS) that was used in the 2314. While I was able
to read the /40 microcode (with occasional glances at a cheat sheet)
I don't recall ever seeing any documentation for the code in the
2314. Does anyone know if it used the same microcode engine?

Joe Morris

stege...@12move.nl

unread,

Apr 4, 2005, 10:06:41 AM4/4/05

to

Joe Morris wrote:

> It's also worth noting that the microcode store on the /40 was the
> same technology (TROS) that was used in the 2314. While I was able
> to read the /40 microcode (with occasional glances at a cheat sheet)
> I don't recall ever seeing any documentation for the code in the
> 2314.
>Does anyone know if it used the same microcode engine?

Got it. It is different and specially designed for the disk controller
function.

Regards Henk
>
> Joe Morris

Sarr J. Blumson

unread,

Apr 4, 2005, 10:42:02 AM4/4/05

to

In article <qh8y3zo...@ruckus.brouhaha.com>,

Eric Smith <er...@brouhaha.com> wrote:
>
>I suspect that the 360/85 microarchitecture became the basis for the
>370/165, but I haven't read the CE manuals so I couldn't say with any
>high degree of certainty.

My memory on this subject is particularly unreliable, but I believe the
165 had virtual memory hardware but the 85 did not.

--
--------
Sarr Blumson sarr.b...@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/

Anne & Lynn Wheeler

unread,

Apr 4, 2005, 11:49:03 AM4/4/05

to

sa...@news.itd.umich.edu (Sarr J. Blumson) writes:
> My memory on this subject is particularly unreliable, but I believe the
> 165 had virtual memory hardware but the 85 did not.

165-ii was a field hardware retrofit of virtual memory hardware to
165s currently in the field ... and it was a significant effort.

system/370 "red book" was the 370 architecture superset of the 370
principle of operations. it was done in cms script (document
formating) with conditionals ....
misc. references to cms done at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
and script and gml
http://www.garlic.com/~lynn/subtopic.html#sgml

when conditionals were set for printing for the 370 principle of
operations ... it left out lots of unannounced stuff ... as well as
all kinds of engineering and other details. there were a number of
features in the original 370 virtual memory architecture that were
never announced.

there was an escallation meeting in POK where the 165 engineers said
that they could do a subset of the (virtual memory) a lot faster than
doing everything in the architecture (which would take an additional
six months). It was eventually decided to do the subset implementation
that could be done six months faster by the 165 engineers. Among the
things that got left out were new memory (segment, page) r/o
protection and some of the selective invalidate commands (aka in
addition to PTLB, there was ISTO, ISTE, IPTE).

Bits and pieces of some of the unannounced 370 virtual memory support
did leak out in later years. however, at the time, the change
resulted in the other 370 products (that had already implemented the
full 370 virtual memory support) having to go back and remove the
extra stuff that the 165 wasn't going to do.

the transition from cp67/cms to vm370/cms ... there was implementation
that would use the new 370 segment protection feature with the cms
shared segment support. with the dropping of the r/o 370 virtual
memory protection support, cms had to revert to a kludge for
maintaining integrity of shared segments across multiple different
virtual address spaces.

the original cms shared segment support was a single segment that was
part of the cms kernel and had this really hacked kludge for
protection. i had converted a bunch of virtual memory management stuff
from cp67 to vm370 (that had never been released in cp67, including
page mapped file system and a lot more extensive shared segment
capability). The vm370 group picked up a small subset of these shared
segment changes (and none of the page mapped file system) for vm370
release 3 ... and called it DCSS. misc. posts related to cms shared
segments, page mapped filesystem, etc
http://www.garlic.com/~lynn/subtopic.html#mmap
http://www.garlic.com/~lynn/subtopic.html#adcon

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Alan Balmer

unread,

Apr 4, 2005, 12:45:22 PM4/4/05

to

On Mon, 04 Apr 2005 00:40:26 GMT, Brian Inglis
<Brian....@SystematicSW.Invalid> wrote:

>>Contrary to what some people have claimed, there is almost no relation
>>between the 360/40 and 360/44 hardware designs. The 360/44 is a very
>>odd beast.
>
>Presumably the 360/44 was either a process or scientific machine?

Yes. When I was at Bausch & Lomb (mid to late 60's), they were doing
breakthrough work in optical design using the 360/44. It's my
understanding that things like the Cinemascope lens and zoom lenses
which stayed in focus were designed on it.

--
Al Balmer
Balmer Consulting
removebalmerc...@att.net

Anne & Lynn Wheeler

unread,

Apr 4, 2005, 1:39:55 PM4/4/05

to

Anne & Lynn Wheeler <ly...@garlic.com> writes:
> 165-ii was a field hardware retrofit of virtual memory hardware to
> 165s currently in the field ... and it was a significant effort.

aka initial 370 announce and ship didn't have virtual memory
support ... virtual memory was announced later and there had
to be hardware retrofit for 155s and 165s

the only 360 with virtual memory support was the 360/67 (except for
the specially modified cambridge 360/40) which had both 24-bit and
32-bit virtual memory address options.

when 370 virtual memory was announced it only had 24-bit addressing.
it wasn't until 370-xa on the 3081 that you saw more than 24-bit
(except it was 31-bit, not 32-bit that had been available on the
360/67).

cambirdge had wanted to add special virtual memory hardware to 360/50
... but there weren't any spare 50s (the spare 50s were all going to
the faa air traffic control system effort) and so had to settle on
modifying a 360/40. the built cp/40 for this machine and later when
360/67 became available, morphed into cp/67.

some of this is also in melinda's history
http://pucc.princeton.edu/~melinda/

Eric Smith

unread,

Apr 4, 2005, 3:35:07 PM4/4/05

to

I wrote:
> I suspect that the 360/85 microarchitecture became the basis for the
> 370/165, but I haven't read the CE manuals so I couldn't say with any
> high degree of certainty.

Sarr J. Blumson wrote:
> My memory on this subject is particularly unreliable, but I believe the
> 165 had virtual memory hardware but the 85 did not.

The 165 did not have dynamic address translation, thus no virtual memory.
The 168 was essentially a 165 with DAT. The 165 could be upgraded (at
huge expense) to add the DAT, becoming a 165-3.

Anne & Lynn Wheeler

unread,

Apr 4, 2005, 4:30:12 PM4/4/05

to

Eric Smith <er...@brouhaha.com> writes:
> The 165 did not have dynamic address translation, thus no virtual memory.
> The 168 was essentially a 165 with DAT. The 165 could be upgraded (at
> huge expense) to add the DAT, becoming a 165-3.

the 155 and 165 had cache and 2mic(?) memory ... and you could get a
field retro-fit of virtual memory hardware.

the 158 & 168 had cache and something like 500ns (480?) memory ... so
cache misses did a lot better. they also came with virtual memory
support as standard. i worked with one of the 165 engineers on vamps
http://www.garlic.com/~lynn/subtopic.html#bounce

i remember him saying that the 165 avg. something like 2.1 machine
cycles per 370 instruction and they improved that for 168 to an
avg. of 1.6 machine cycles per 370 instruction.

the 168-1 to 168-3 transition involved doubling the cache size from
32k to 64k. it turned at that they were using the 2k bit to index the
extra cache lines (trying to some of the indexing bits that were the
same whether it was a virtual or real address). this caused a
performance degradation running any of the 2k-page operating systems
(vs1, dos/vs) under vm on 168-3. in virtual 2k page mode the 168-3 ran
with half the cache (essentially reverted to 168-1). The problem with
running under VM would be that every time you entered the vm kernel,
it would switch to 4k page mode ... which flushed and reset the
complete cache ... and then switching back to 2k page mode with shadow
page tables again flushed and reset the complete cache. as a result,
running a 168-3 in these environments was actually much worse than
running with a 168-1 ... since the cache flush and reset (with
constant switch between 2k & 4k page modes) was causing a lot of
additional overing

158 was microcoded machine with integrated channels ... aka the native
engine was shared between executing the microcode for channel
operation and the microcode for 370 processor operation.

for the 303x follow-on they introduced a "channel director". the
channel director was basically a 158 native engine running only the
158 integrated channel microcode (and no 370 microcode). A 3031 was a
158 native engine running only the 370 microcode (and no integrated
channel microcode) and reconfigured to work in conjunction with a
channel director (in effect two processor shared memory .... but the
engines were running completely different m'code). The 3032 was a 168
reconfigured to work with channel director. A 3033 started out
effectively being the 168 wiring diagram remapped to faster technology
(and configured to work with channel directors).

Lee Courtney

unread,

Apr 5, 2005, 12:30:47 PM4/5/05

to

At HP we went though what I believe was a similar exercise with the HP 3000
Series 64. When VISION was delayed in lieu of SPECTRUM, the 3000 product
line was in a bad place with no imminent performance upgrade in the
pipeline. As a stop-gap measure we shipped disc-caching as the Series 68 and
Series 70. When the customer upgraded they got a new face-plate (64-68) and
a microcode tape. I believe the 70 included additional memory (important for
disc caching). But, many customers were under-whelmed with the amount of
change they saw for the dollars they paid. However, a great product with
lots of customer benefit that really saved HP's bacon at the time.

Sounds like the 168 was a field upgrade from the 165. Was the original 165
designed to accommodate virtual memory, or was VM an after-thought?

On a related note I am assuming that the 158 did not share any lineage with
the 155? That the 155 was more a backwards leaning 360'ish machine than
forward leaning 370 architecture machine. The timing of the 155/165 relative
to the 158/168 announcements might lead one to believe there was some
linkage between the systems.

Thanks!

Lee Courtney

"Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
news:m3vf729...@lhwlinux.garlic.com...

CBFalconer

unread,

Apr 5, 2005, 12:59:45 PM4/5/05

to

Lee Courtney wrote:
>
> At HP we went though what I believe was a similar exercise with the
> HP 3000 Series 64. When VISION was delayed in lieu of SPECTRUM, the
> 3000 product line was in a bad place with no imminent performance
> upgrade in the pipeline. As a stop-gap measure we shipped
> disc-caching as the Series 68 and Series 70. When the customer
> upgraded they got a new face-plate (64-68) and a microcode tape. I
> believe the 70 included additional memory (important for disc
> caching). But, many customers were under-whelmed with the amount of
> change they saw for the dollars they paid. However, a great product
> with lots of customer benefit that really saved HP's bacon at the
> time.

The most ridiculous HP3000 upgrade was the first, when they went
from 128 kB to 512 kB in four banks. Why they didn't have the
sense to arrange for more banks in that architecture beat me then,
and still beats me today. We had one of the first machines at
Yale-New Haven Hospital, and were performance limited for about 10
years.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

Anne & Lynn Wheeler

unread,

Apr 5, 2005, 1:37:46 PM4/5/05

to

"Lee Courtney" <lcou...@NOSPAM-mvista.com> writes:
> At HP we went though what I believe was a similar exercise with the
> HP 3000 Series 64. When VISION was delayed in lieu of SPECTRUM, the
> 3000 product line was in a bad place with no imminent performance
> upgrade in the pipeline. As a stop-gap measure we shipped
> disc-caching as the Series 68 and Series 70. When the customer
> upgraded they got a new face-plate (64-68) and a microcode tape. I
> believe the 70 included additional memory (important for disc
> caching). But, many customers were under-whelmed with the amount of
> change they saw for the dollars they paid. However, a great product
> with lots of customer benefit that really saved HP's bacon at the
> time.
>
> Sounds like the 168 was a field upgrade from the 165. Was the
> original 165 designed to accommodate virtual memory, or was VM an
> after-thought?
>
> On a related note I am assuming that the 158 did not share any
> lineage with the 155? That the 155 was more a backwards leaning
> 360'ish machine than forward leaning 370 architecture machine. The
> timing of the 155/165 relative to the 158/168 announcements might
> lead one to believe there was some linkage between the systems.
>
> Thanks!
>
> Lee Courtney

158/168 were new technology ... compared to 155/165 ... especially the
faster real memory technology. however, i believe the architecture of
the native engines were the same and so the same microcode could work.

155/165 weren't designed for virtual memory and required extensive
hardware retrofit to install it in existing boxes.

in the early 70s ... most of my POK visits involved 370 architecture
meetings ... and didn't run into many cpu engineers ... other than who
might show up in such meetings.

in the mid/late 70s ... i got involved with the cpu engineers working
on the 3033 ... i was even invited to their weekly after work events,
if i happened to be in town (honorary cpu engineer?).

part of the issue was that 370 (non-virtual memory) was just an
interim/stop-gap. the real followon was going to be FS (future
system). there was huge resources poured into FS ... and it was
finally canceled w/o being announced (and few were even aware of it).
http://www.garlic.com/~lynn/subtopic.html#futuresys

as noted in previous posts on FS ... i didn't make myself very popular
with the FS crowd ... somewhat panning their effort (there was this
long-playing cult film down in central sq ... and I made the analogy
to FS of the inmates being in charge of the asylum).

as in other references to FS, FS was supposedly spawned by the emergence
of the 360 control clone market ... example:
http://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System

... aka in above refernece it mentions that 2500 were initially
assigned to the project.

I worked on a project as an undergraduate that created a clone
telecommunication controller (reverse engineer the ibm channel,
adapt a interdata/3, etc)
http://www.garlic.com/~lynn/subtopic.html#360pcm

there later was a write up blaiming the four of us for spawning
the controller clone business.

FS may have then contributed to creating 370 clone mainframe market.
Amdahl may have left to form his own 370 company in disagreement over
the FS direction/strategy (as opposed to bigger, faster 370).
http://www.garlic.com/~lynn/2005e.html#29 Using the Cache to Change the Width of Memory
http://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other gods before the ANSI C standard

Wally B

unread,

Apr 5, 2005, 10:47:09 PM4/5/05

to

On Mon, 4 Apr 2005 12:50:59 +0000 (UTC), Joe Morris

>I don't recall ever seeing any documentation for the code in the
>2314. Does anyone know if it used the same microcode engine?

The 2314 had almost an identical microword as the 2841, which
was the first 360 DASD controller and supported the 2311, 2302,
and the 2321 (I think that was the number) strip file. The 2841
started off using CCROS (Card Capacitor ROS), and changed
to TROS in mid project because CCROS was so unreliable. The
original 2841 had an 8 bit ALU that was lifted from the MOD 30
design. That ALU was an interesting design in that it was fully
checked against any single circuit failure, but with a design where
the circuitry doing the checking actually improved the speed of
the ALU as well. Later versious of the 2841 had a cost
reduced ALU which wasn't based on the MOD 30's self checking
design (the redesign saved almost a whole board of logic, as I
recall)

I don't have documentation on the 2841 microword, but I suspect
that I can figure out most of it. The ALU had two inputs (A and
B), and there were about 20 registers, as I recall. So, I think there
was:
5 bits to select the first ALU input register (for each cycle)
4 bits to select the second ALU input (not all regs useable on B)
5 bits to select the ALU output target
3 bits to select the ALU operation
6 bits for the next microword address bits [7-2]
4 bits to select the value of or one of 14 test objects for
setting bit[1] of the next microword address
4 bits to select the value of or one of 14 test objects for
setting bit[0] of the next microword address
8 bits for the constant field, which could be gated to
input B. This was a dual use field, and was also used
to select bits [12-8] of the next microword, when
necessary.
4 bits which decoded to setting or resetting one
of 8 status bits
That adds up to a 43 bit microword, which seems about
right. I think that TROS supported about a half dozen
more bits that we used in the 2841 microword.

Since the two low order bits of the next address could
derived from various things that the microcode needed
to test, it was possible for every instruction to be branching
on two different things, and hence have four possible
successor microwords. As I recall, about half of the
instructions of the microcode load were in fact branching
on two different test objects, about a 30% were only
branching on one thing, and 20% had only a single
successor microinstruction.

(I wrote about 80% of the microcode for the 2841, and
also wrote something called the 2x8 inline diagnostics
for the 2844, which was a version of the 2314 with 2x8
switching of 8 drives between two control units.)

Wally Bass

Dan Koren

unread,

Apr 5, 2005, 11:13:46 PM4/5/05

to

"Eric Smith" <er...@brouhaha.com> wrote in message
news:qh8y3zo...@ruckus.brouhaha.com...

> John Savard wrote:
>> I have learned some interesting
>> and unexpected facts about the use of microcode with the IBM
>> System/360.
>
> Hardwired: 360/44 360/75 360/91 360/95 360/195 370/195
>

The 370/195 was a masterpiece of processor architecture
that has yet to be matched, let alone surpassed.... ;-)

dk

PS. ... showing my age I suppose.

jsa...@ecn.ab.ca

unread,

Apr 6, 2005, 12:21:12 AM4/6/05

to

Dan Koren wrote:

> The 370/195 was a masterpiece of processor architecture
> that has yet to be matched, let alone surpassed.... ;-)

Al Kossow's site has the schematics for the Model 30.

Interestingly enough, Microprogramming Principles and Practices, by
Samir S. Husson, which describes the microcode of the Model 40 and 50
in detail, also gives a brief account of the microcode formats for
models 20, 25, and 85, does not say much about the Model 30.

But Computer Structures: Readings and Examples gives a description of
the Model 30 microprogram format.

U. S. Patent 3,400,371 describes one of the models of the IBM
System/360; U. S. Patent 3,315,235 presumably describes a different
one. I shall have to see if I can, from these other references,
determine which models they refer to.

It is too bad that he doesn't have the schematics of the Model 195; I
had always thought they might make a helpful starting point for someone
designing a Pentium-class microprocessor.

I would definitely agree that the Pentium doesn't surpass the 195 in
elegance, but there are other machines that have reaped praise between
then and now, such as the Cray-1.

John Savard

Dan Koren

unread,

Apr 6, 2005, 1:50:44 AM4/6/05

to

<jsa...@ecn.ab.ca> wrote in message
news:1112761272.3...@f14g2000cwb.googlegroups.com...

> Dan Koren wrote:
>
>> The 370/195 was a masterpiece of processor architecture
>> that has yet to be matched, let alone surpassed.... ;-)
>
> Al Kossow's site has the schematics for the Model 30.

I was only referring to the 370/195. I have never worked
on a /30. In fact, the smallest 360/370 machine I touched
was a 360/67.

> Interestingly enough, Microprogramming Principles and Practices, by
> Samir S. Husson, which describes the microcode of the Model 40 and 50
> in detail, also gives a brief account of the microcode formats for
> models 20, 25, and 85, does not say much about the Model 30.
>
> But Computer Structures: Readings and Examples gives a description of
> the Model 30 microprogram format.

The 370/195 was hardwired. Microprogramming is cheating! ;-)

> U. S. Patent 3,400,371 describes one of the models of the IBM
> System/360; U. S. Patent 3,315,235 presumably describes a different
> one. I shall have to see if I can, from these other references,
> determine which models they refer to.
>
> It is too bad that he doesn't have the schematics of the Model 195; I
> had always thought they might make a helpful starting point for someone
> designing a Pentium-class microprocessor.
>
> I would definitely agree that the Pentium doesn't surpass the 195 in
> elegance, but there are other machines that have reaped praise between
> then and now, such as the Cray-1.

Count the 370/195 pipeline stages and you will get an
interesting number... ;-)

The Cray machines excel(led) at vector processing, but
did not have as aggressive pipelines as the 370/195. In
fact, I'm not sure anything else even came close....

dk

Rupert Pigott

unread,

Apr 6, 2005, 7:55:02 AM4/6/05

to

Dan Koren wrote:

[SNIP]

> The Cray machines excel(led) at vector processing, but
> did not have as aggressive pipelines as the 370/195. In
> fact, I'm not sure anything else even came close....

What I've learnt about the 370/195 in this NG has whetted
my appetite somewhat, it does sound impressive. I'd quite
happily queue to see those schematics myself. The same
goes for IBM's ACS, Smotherman's site has whetted my
appetite. :)

The schematics of Manchester University's MU5 would make
for some interesting reading too. It was a rather odd (and
very large) asynchronous machine that had a number of
unusual architectural features. AFAICT it could be
classified as superpipelined and superscalar.

Cheers,
Rupert

MSCHAEF.COM

unread,

Apr 6, 2005, 9:59:53 AM4/6/05

to

In article <1112761272.3...@f14g2000cwb.googlegroups.com>,
<jsa...@ecn.ab.ca> wrote:
...

>It is too bad that he doesn't have the schematics of the Model 195; I
>had always thought they might make a helpful starting point for someone
>designing a Pentium-class microprocessor.
>
>I would definitely agree that the Pentium doesn't surpass the 195 in
>elegance,

Can anybody talk a little more about what made the 195 special?

thanks,
Mike
--
http://www.mschaef.com

Anne & Lynn Wheeler

unread,

Apr 6, 2005, 11:27:32 AM4/6/05

to

msc...@fnord.io.com (MSCHAEF.COM) writes:
> Can anybody talk a little more about what made the 195 special?

an unrelated 195 story ... the 195 had 64 instructions in the pipeline
and no branch prediction ... a branch (that wasn't to an instruction
already in the pipeline ... aka loop) would cause the pipeline to
draine. unless it was very specialized looping codes ... normal
instruction stream ran the 195 at about half peak ... because of the
frequence of branches.

i got somewhat involved when the 195 product engineers were looking at
adding two processor 195 support ... actually the original
hyperthreading (that intel processors have recently gone thru a
phase); basically a second set of registers and psw and the pipeline
would have red/black flag ... indicating which instruction stream
stuff was associated with. it looked like SMP to software ... but to
the hardware it was hyperthreading two instruction streams (dual
i-stream). the idea was that if avg. software only kept the pipeline
half full because of branches ... that two instruction streams had a
chance of keeping the pipeline full ... and achieving peak instruction
processing rates (these machines had no caches ... and so were much
more sensitive to memory latencies).

however, it was never announced and shipped.

sjr/bld28 still had a 195 in the late 70s ... running heavy batch
workload. palo alto science center had an application that they
submitted ... but because of the processing queue ... it only got run
about once every three months. pasc finally did some work on the
application for checkpointing and running under cms batch in the
background on their 370/145 vm/cms system. it would soak up spare
cycles on the machine offshift and weekends. the elapsed time was
slightly better than the 3month turnaround at the sjr 195 (because of
the long work queue).

gpd was also running an application on the 195 that was getting
excessive long turn arounds ... air bearing simulation ... for design
of the new disk floating heads.

we had done this work over in the disk enginnering lab (bldg 14) and
product test lab (bldg 15) so that they could run under operating
system environment. prior to that, they were running dedicated
stand-alone ... they had tried MVS at one time and were getting about
15minutes MTBF when running a single test cell. bullet proofing the
operating system I/O subsytem allowed them to operate half-dozen or so
test cells concurrently w/o failing.
http://www.garlic.com/~lynn/subtopic.html#disk

in any case, the disk product test lab in bldg. 15 tended to get
something like the 3rd machine model ... after the first two that cpu
engineers were testing with. because of the operating system work for
the disk guys ... i would have access to these new machines. when
endicott was building the 4341 ... the endicott performance people
asked me to do benchmarks on the bldg. 15 4341 (because i had better
access to a 4341 than they did in endicott).

anyway, bldg. 15 also got an early 3033. 3033 ran about half the speed
of 195 peak ... but about the same as the 195 for most normal
workloads. while the disk regression tests in bldg. 15 were i/o
intensive ... they bairly blimped the cpu meter. so one of the things
we thought would be useful was get the air bearing simulation
application up and running on the bldg. 15 3033 ... where it could
soak up almost the complete cpu with little competition ... much
better than a couple turn-arounds a month on 195 across the street in
sjr/28.

minor past posts mentioning the air bearing simulation application:
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004b.html#15 harddisk in space
http://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns

http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone

http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns

jsa...@ecn.ab.ca

unread,

Apr 6, 2005, 12:03:21 PM4/6/05

to

Eric Smith wrote:

> Contrary to what some people have claimed, there is almost no
relation
> between the 360/40 and 360/44 hardware designs. The 360/44 is a very
> odd beast.

I have found one piece of evidence indicating _some_ relation.

A Field Engineering manual on Al Kossow's site notes the meaning of
prefix characters for diagnostic programs.

The table runs:

0 - Special system (non-System/360)
1 - Not used
2 - Used by Model 20
3 - Used by Model 30
4 - Used by Models 40/44
5 - Used by Model 50
6 - Used by Models 65/67
7 - Used by Model 75
8 - Used by Model 85
9 - Used by Models 91/95
A - On line test
B - Not used
C - Used by Model 25
D - Special system (FAA 9020)
E - Used by some systems but not by all
F - Applicable to all systems

page 3-1 of SY22-2851-1.

Now, it is odd that the Model 40 and 44 would both have the same
Diagnose instruction given that the Model 44 was not capable of
executing Model 40 microcode.

At least, I assume that to be the case, and that even the "Dublin
Emulator" was written in regular 360/44 machine code.

To me, it would not seem unnatural for the 360/44 to have had the same
ALU as the 360/40, just controlled by hardwired control instead of
microcode; however, the problem with that approach, of course, is that
the 360/44 couldn't have achieved its observed performance advantage
over the 360/40 for scientific problems in that fashion.

Given that the commercial instruction set was not available for it, of
course, it used different software than all the other models. (But
given *that*, it was rather disingenuous for IBM to refer to the
commercial instruction set as an "option" on the other models!)

John Savard

jsa...@ecn.ab.ca

unread,

Apr 6, 2005, 12:42:10 PM4/6/05

to

MSCHAEF.COM wrote:

> Can anybody talk a little more about what made the 195 special?

I know what made it special to an extent, but not what made it _as_
special as the previous poster had said.

IBM built the Model 91 computer as its "top-of-the-line" machine. It
had an elegant new pipelined arithmetic unit using some algorithms not
entirely surpassed today, and it used hardwired control for maximum
speed.

It also built the Model 85 computer which was located between its
previous top-of-the-line machine, the Model 75, and the Model 91.

But the Model 85 turned out to be very nearly as fast as the Model 91.
IBM had serious problems with its last attempt at a pipelined machine,
the STRETCH, and this might well have killed pipelines at IBM. But
instead, IBM persevered, perhaps with Gene Amdahl exercising his
persuasive skills to the limit... and perhaps because the 91 was
clearly not a total flop; pipelines were helping this time, even if
less so than expected.

The Model 91 had a top memory size of 4 megabytes.

IBM had made, for NASA, two Model 95 computers which had a thin-film
main memory of 1 megabyte; the same four megabytes of core served as
bulk core. They were IBM's only well-known machines with thin-film
memory (there may have been a few military systems as well).

In any event, the Model 195 was basically a Model 91 with a 32K cache
made from that up-and-coming technology, semiconductor RAM.

If the 85 had performed less well, perhaps the Model 95 would have been
made in larger quantities, since IBM *had* finally figured out how to
get thin film memory to work - but since a small cache was seen to have
nearly all the benefits of a faster main memory, although semiconductor
RAM was much more expensive than thin-film per bit, having a much
smaller cache that was twice as fast was the way to go; about the same
price, almost twice the performance.

Plus the image benefits of using the "latest technology" instead of
something about to become old hat. Pity that thin film was too
expensive for IBM to offer four megabytes of *that* as an option for
the 360/195. Or, for that matter, sixteen. How much more can it
possibly cost to bring a few more address lines out of the box?

But then that applies to today's 64-bit microprocessors too. Why just
40 or 48 bit addresses? Bring the signals out to pins, and let
implementors decide if they want to make use of them.

In any event, this means that a set of schematics for the Model 91 are
almost as good, as far as *I* know. There may be other enhancements to
the 195 besides the cache that gave it its unique status. Of course,
the fact that there was a 370/195 as well is another plus for that
design.

John Savard

jsa...@ecn.ab.ca

unread,

Apr 6, 2005, 1:07:08 PM4/6/05

to

jsa...@ecn.ab.ca wrote:
> U. S. Patent 3,400,371 describes one of the models of the IBM
> System/360; U. S. Patent 3,315,235 presumably describes a different
> one.

Looking at the diagrams of the internal registers and data flow of the
machine in the two patents, apparently they describe the same machine.

Pages 647 through 938 of Patent 3,400,371 apparently contain a complete
listing of the microcode of the model described therein; but the
microcode seems to have a 64-bit word, which doesn't match any of the
actual 360 models.

Doubtless closer study will explain this.

John Savard

Anne & Lynn Wheeler

unread,

Apr 6, 2005, 2:18:51 PM4/6/05

to

ref:
http://www.garlic.com/~lynn/2005f.html#4 System/360, Hardwired vs. Microcoded

195 ran about 10mips peak ... but most normal codes (not specifically
designed for looping in the pipeline) ran more like 5mips.

related to previous post about 168 ... 168-3 was about a 3mips
machine
http://www.garlic.com/~lynn/2005f.html#1 System/360, Hardwired vs. Microcoded

the 3033 started out being a mapping of the 168 design to faster chip
technology resulting in about 20% higher mips. the chips in the 3033
were much higher density than those used in 168 (by about factor of
ten times) ... but the design started out only using the same number
of cicuits/chip as in the 168 original implementatation. part-way thru
the design ... there was an effort to do partial redesign and leverage
much higher circuit chip density ... which brought the 3033 up to
about 4.5mips (50% more than 168).

moving the air bearing simulation application from the sjr/28 195 to
the 3033 in bldg.15 ran about the same speed ... but the 3033 was
effectively cpu idle with no backlog (of cpu related work) ...
significantly improving the design cycle for the new 3380 floating
heads
http://www.garlic.com/~lynn/subtopic.html#disk

Peter Flass

unread,

Apr 6, 2005, 4:29:28 PM4/6/05

to

jsa...@ecn.ab.ca wrote:

> In my recent reading and web searches, I have learned some interesting

> and unexpected facts about the use of microcode with the IBM
> System/360.
>

> I knew that of the original 360 models, only the Model 75 was
> hardwired, the rest being microcoded. And, I believe I have heard that
> the Model 195, and, by extension, the Model 91 and 95, were also
> hardwired.
>
> But I was surprised to learn, recently, that the Model 85 used
> microcode. According to the article I read that mentioned this, IBM
> would have used microcode for the 75, but was forced to use hardwired
> logic because they had no sufficiently fast read-only memory available.

>
> But even more recently, I learned something even more startling. The
> IBM System/360 Model 40 definitely was microprogrammed; a FE manual on
> Al Kossow's site shows the microcode format for it.
>

> But, according to the Functional Characteristics book for the Model 44,
> it, too, had *hardwired* control logic. This let it run faster, but
> meant that the decimal and character instructions were not available as
> options for it.
>
> John Savard
>

The /44 was intended as a process-control, laboratory, or "scientific"
computer. IIRC, it had its own control program, the Model-44 PS, and
I'm not sure it could run any of the standard OS's. Remember also that
the decimal instruction set was an option on many 360's, as was the
floating-point instruction set. I worked on many 360's without FP.

Eric Sosman

unread,

Apr 6, 2005, 5:59:25 PM4/6/05

to

Peter Flass wrote:

> jsa...@ecn.ab.ca wrote:
>
> The /44 was intended as a process-control, laboratory, or "scientific"
> computer. IIRC, it had its own control program, the Model-44 PS, and
> I'm not sure it could run any of the standard OS's. Remember also that
> the decimal instruction set was an option on many 360's, as was the
> floating-point instruction set. I worked on many 360's without FP.

44PS was the "native" operating system. There was some
extra-cost hardware and software that provided a slow emulator
for the missing instructions (plus hardware implementations of
a few of them), and this let the machine run DOS or OS slowly.
My college had a 44 that was time-shared between administration
and academics: It ran 44PS from noon to midnight for students
and faculty, and DOS from midnight to noon so the admin folks
could run their COBOL and RPG (thanks to the emulator).

The weirdest addition to the machine was an 18-- um, 1832?
digital-to-analog converter, funded by the school's Conservatory
of Music. We used adaptations of code developed by Max Matthews
at Bell Labs to synthesize music (all right, "sound") by computing
discrete samples at whatever rate was desired, and then there was
this rather amazing program to stream the pre-computed values
through the 18xx and drive as many as four output channels. We
also played little games by hooking the outputs to oscilloscopes
in various ways to generate graphics -- the images were less good
than one could produce on the line printer, but were *way* cooler.

--
Eric....@sun.com

Eric Smith

unread,

Apr 6, 2005, 7:12:54 PM4/6/05

to

jsa...@ecn.ab.ca writes:
> But the Model 85 turned out to be very nearly as fast as the Model 91.
> IBM had serious problems with its last attempt at a pipelined machine,
> the STRETCH, and this might well have killed pipelines at IBM. But
> instead, IBM persevered, perhaps with Gene Amdahl exercising his
> persuasive skills to the limit... and perhaps because the 91 was
> clearly not a total flop; pipelines were helping this time, even if
> less so than expected.

That's not a different story than Stretch (aka IBM 7030 Data Processing
System). On Stretch, the pipelines were helping, even if less so than
expected.

Eric

Eric Smith

unread,

Apr 6, 2005, 7:21:31 PM4/6/05

to

I wrote:
> Contrary to what some people have claimed, there is almost no relation
> between the 360/40 and 360/44 hardware designs. The 360/44 is a very
> odd beast.

jsa...@ecn.ab.ca writes:
> I have found one piece of evidence indicating _some_ relation.
> A Field Engineering manual on Al Kossow's site notes the meaning of
> prefix characters for diagnostic programs.

[...]

> 2 - Used by Model 20
> 3 - Used by Model 30
> 4 - Used by Models 40/44
> 5 - Used by Model 50
> 6 - Used by Models 65/67
> 7 - Used by Model 75
> 8 - Used by Model 85
> 9 - Used by Models 91/95

That doesn't demonstrate any similarity between the 40 and 44, only that
the diagnostic part number prefixes were mnemonic in nature. I expect that
after they introduced the model 25, its diagnostic prefix was probably
"2", but it didn't have much in common with the model 20.

> To me, it would not seem unnatural for the 360/44 to have had the same
> ALU as the 360/40,

I doubt very much that it did. By the time the 44 was designed, the 40
design was pretty long in the tooth. It seems far more likely that the
44 design would have used an ALU design similar to that of the 65.

Eric

jsa...@ecn.ab.ca

unread,

Apr 6, 2005, 8:18:43 PM4/6/05

to

Eric Smith wrote:
> I expect that
> after they introduced the model 25, its diagnostic prefix was
probably
> "2", but it didn't have much in common with the model 20.

No, it was C.

> I doubt very much that it did. By the time the 44 was designed, the
40
> design was pretty long in the tooth. It seems far more likely that
the
> 44 design would have used an ALU design similar to that of the 65.

You may well be right. Looking at an old book on computers, even the
Model 75 just had a 64-bit adder, plus an 8-bit exponent adder and an
8-bit BCD adder. Just enough to implement the 360 instruction set with
reasonable directness, like any number of traditional computers that
preceded it.

Nothing fancy, like we are used to in today's advanced microcomputers,
or as appeared in such machines as the Control Data 6600 and the IBM
360/91.

Incidentally, since pipelining is a form of parallelism - instructions
are being executed side-by-side which cannot be logically dependent on
each other - a machine with a design on the level of the 360/75 can
have the same *worst-case* performance as an advanced design using far
more transistors, even if the advanced design can have vastly higher
performance on some problems.

There have already been ECL microprocessors made, such as one by MIPS a
while back; I think it was the R6000.

Smaller and smaller CMOS gates, though, seem to imply that ECL is
surpassed by CMOS in speed; BiCMOS is referred to as passe in some
places. If there is no way to improve worst-case performance above what
today's microprocessors provide, supercomputing in the "traditional"
sense, as opposed by supercomputing by tying together commodity
components, is indeed impossible.

John Savard

Eric Smith

unread,

Apr 6, 2005, 8:58:04 PM4/6/05

to

I wrote:
> I expect that after they introduced the model 25, its diagnostic
> prefix was probably "2", but it didn't have much in common with the
> model 20.

jsa...@ecn.ab.ca writes:
> No, it was C.

Oops, missed that in your table. Well, I still think it was mostly
mnemonic and not particular an indication that there was commonality
of design. At some point they probably decided that it wasn't
reasonable to try to assign a unique letter to every forthcoming
model.

Eric

jsa...@ecn.ab.ca

unread,

Apr 6, 2005, 11:08:11 PM4/6/05

to

Eric Smith wrote:

> Oops, missed that in your table. Well, I still think it was mostly
> mnemonic and not particular an indication that there was commonality
> of design. At some point they probably decided that it wasn't
> reasonable to try to assign a unique letter to every forthcoming
> model.

You may well be right. As the owner of the Retrocomputing site, you
would know more about these things than I would, although there are
people out there who know more than both of us.

I noted, in another thread, that the Model 75 was pretty conventional
as a computer; according to one book describing it innards, it got by
with a 64-bit adder, another 8-bit adder for exponents, and an 8-bit
BCD adder for decimal instructions (apparently also usable in binary
for string compares).

But I find that the PDP-10, another conventional computer in that
sense, had a performance much smaller than that of a 360/75, one
comparable with the 360/50. Thus, the Model 75 obviously had something
going for it. The same source shows the 360/44 slightly outperforming
the 360/75; but it shows the 360/65 outperforming them both, so it may
not be entirely accurate. (It attempts to normalize MIPS figures across
performance measures over time so as to be able to compare everything
from the Harvard Mark I to the NEC Earth Simulator; this is a difficult
task, and so some inaccuracies come with the territory.)

Clearly, the Model 44 was designed in response to competitive
pressures. And giving it the option of running the commercial
instruction set was avoided, to prevent it from eating into sales of
the rest of IBM's product line. Just how they did that - well, as I
noted, Pugh, Johnson, and Palmer apparently doesn't even *mention* the
360/44.

John Savard

Dan Koren

unread,

Apr 7, 2005, 1:18:13 AM4/7/05

to

"MSCHAEF.COM" <msc...@fnord.io.com> wrote in message
news:ZcqdnSz8uMj...@io.com...

The 370/195 was a heroic design,
comparable to thenBoeing 747-SP ;-)

Hardwired logic and a very deep
pipeline.

BTW after 35 years in the industry I
am more convinced than ever that hard
wired logic reigns supreme and that
microcode is evil.... ;-)

dk

arargh5...@now.at.arargh.com

unread,

Apr 7, 2005, 3:28:13 AM4/7/05

to

On Thu, 7 Apr 2005 01:18:13 -0400, "Dan Koren" <dank...@yahoo.com>
wrote:

<snip>

>Hardwired logic and a very deep
>pipeline.
>
>BTW after 35 years in the industry I
>am more convinced than ever that hard
>wired logic reigns supreme and that
>microcode is evil.... ;-)

Maybe. But, I bet it's boatloads cheaper. :-)

--
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

jmfb...@aol.com

unread,

Apr 7, 2005, 7:04:29 AM4/7/05

to

In article <4254...@news.meer.net>,

ROTFLMAO. I thought that the first time I met one.

/BAH

Subtract a hundred and four for e-mail.

Henk Stegeman

unread,

Apr 7, 2005, 2:56:57 PM4/7/05

to

>
> I don't have documentation on the 2841 microword, but I suspect
> that I can figure out most of it.

Hi Wally
I do have documentation on the 2841 microword.

Here it is:
CA: 4+Alt bits to select the first ALU input register (for each cycle)
CB: 2 bits to select the second ALU input (not all regs useable on B)
CD: 4+Alt bits to select the ALU output target
CV: 1 bit for true/complement input to ALU
CC: 3 bits to select the ALU operation
CN: 6 bits for the next microword address bits [7-2]
CL: 4 bits to select the value of or one of 14 test objects for

setting bit[1] of the next microword address

CH: 4 bits to select the value of or one of 14 test objects for

setting bit[0] of the next microword address

CK: 8 bits for the constant field, which could be gated to

input B. This was a dual use field, and was also used
to select bits [12-8] of the next microword, when
necessary.

CS: 4 bits which decoded to setting or resetting one
of 8 status bits

Very good score !!!

The CM, CU, CF and CG fields (memory control) where used on the /30 but not
in the 2314.

Henk Stegeman

hanc...@bbs.cpcn.com

unread,

Apr 12, 2005, 2:34:36 PM4/12/05

to

Dan Koren wrote:
> The 370/195 was a masterpiece of processor architecture
> that has yet to be matched, let alone surpassed.... ;-)

I'm still confused as to the differences, if any, between
the S/360-195 and the S/370-195. Could anyone explain
the differences and how many built? (I think even
the S/360 version had monolithic storage). I gather
that both models evolved out of work for the S/360-91.

If I understood the Pugh S/360 book correctly, there
were very view model 195s built (either 360 or 370)
and it was more of a prestige kind of machine--fast,
but a money loser due to high construction expense?

In Tom Watson's memoirs (Father Son & Co) he says
(in long hindsight) that building supercomputers
was a specialty, like building sports cars. Control
Data (with Seymour Cray) was good at it, kind of like
the Porsche of computing. IBM was more of a General
Motors, building for a mass market.

Anne & Lynn Wheeler

unread,

Apr 12, 2005, 3:48:05 PM4/12/05

to

hanc...@bbs.cpcn.com writes:
> I'm still confused as to the differences, if any, between the
> S/360-195 and the S/370-195. Could anyone explain the differences
> and how many built? (I think even the S/360 version had monolithic
> storage). I gather that both models evolved out of work for the
> S/360-91.

the 370/195 had the "new" (non-virtual memory) 370 instructions (like
insert character under mask, etc).

i was also told the 370/195 had better fault tolerant characteristics
and some retry of soft-errors (compared to 360/195) ... some statistic
that the number of components in the 195 ... the probability of some
kind of soft failures was on the order of daily..

sjr had 195 up thru the late 70s ... and besides the supercomputer
venue some of the large financial houses and airlines had them for
high end transaction processing (financial transaction switching and
airline res system). the eastern airline res system was one of that i
believe ran on 195 (south florida) and was part of the input into
amadeus (my wife served stint as amadeus chief architect for a time).

that was one of the recent references to the nail in FS (future
system) coffin
http://www.garlic.com/~lynn/2005f.html#19 Where should the type information be: in tags and descriptors

i got involved with the 195 group when they were look at adding dual
i-stream support to 370/195 ... from the software standpoint it would
look like dual-processor operation ... but it was very akin to the
recent processor hardware threading ... aka the scenario was that most
codes weren't able to keep the pipeline full because most branches
causing pipeline stall/drain (mip/thruput nominally was about half of
peak). there was some hope that dual i-stream support would keep the
pipeline full ... and show aggregate peak thruput.

recent past post in this thread
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded

Dan Koren

unread,

Apr 12, 2005, 7:36:46 PM4/12/05

to

<hanc...@bbs.cpcn.com> wrote in message
news:1113330876.2...@f14g2000cwb.googlegroups.com...

>
>
> If I understood the Pugh S/360 book correctly, there
> were very view model 195s built (either 360 or 370)
> and it was more of a prestige kind of machine--fast,
> but a money loser due to high construction expense?
>

Not an issue for the kind of
applications I was working on
at the time.... ;-)

dk

Anne & Lynn Wheeler

unread,

Apr 12, 2005, 7:57:29 PM4/12/05

to

the death of FS also saw the (re-)ascension of marketing, accountants, and MBAs.
http://www.garlic.com/~lynn/subtopic.html#futuresys

801/risc could be viewed as a swinging to the opposite extreme
... demonstrating with cp.r and pl.8 software technology could
be used to compensate for extremely simple hardware
(lack of features)
http://www.garlic.com/~lynn/subtopic.html#801

glen herrmannsfeldt

unread,

Apr 18, 2005, 3:43:51 AM4/18/05

to

Anne & Lynn Wheeler wrote:

> sa...@news.itd.umich.edu (Sarr J. Blumson) writes:

>>My memory on this subject is particularly unreliable, but I believe the
>>165 had virtual memory hardware but the 85 did not.

> 165-ii was a field hardware retrofit of virtual memory hardware to
> 165s currently in the field ... and it was a significant effort.

The 165 seems to have some imprecise interrupts, at least more than
I would have otherwise expected. Those don't work very will with DAT,
so did they have to fix them, too?

-- glen

glen herrmannsfeldt

unread,

Apr 18, 2005, 3:55:39 AM4/18/05

to

jsa...@ecn.ab.ca wrote:

(snip)

> In any event, the Model 195 was basically a Model 91 with a 32K cache
> made from that up-and-coming technology, semiconductor RAM.

As I understand it, the 91 was the first commercial machine using
semiconductor RAM. I believe 4 bit chips, for the storage keys,
or maybe it was 16. Fast, but small.

-- glen