By Any Other Name

[Quadibloc]

While the Honeywell 1800 is compatible with the 400, the 800, and the
Datamatic 1000, apparently the Honeywell 300 isn't, since it uses 24
bit integers instead of 45 bit integers.

In looking for Honeywell 300 information, I came across the
appointment of an individual as President of a society for Honeywell
300 and 1800 programmers, so I checked out the 1800 manual on Al
Kossow's site.

In any event, though, I noticed a mention of the language Automath in
that manual. It was mentioned as a scientific programming language
that provided functionality equivalent to what FORTRAN provided.

Searches for more information on this language turned up claims that
Automath _was_ a dialect of FORTRAN, with a different name slapped on.

And that reminded me of Philco's ALTAC language. Now, here was a
language which was not compatible with FORTRAN.

Because columns 1 through 8 of the card contained the identification
sequence that the computer ignored so you could punch in numbers to
let you put the cards in the right order if you dropped them.

Columns 9 through 15 contained the statement number; column 16
indicated a continuation card, and columns 17 through 80 contained the
statement.

Otherwise, it was equivalent to FORTRAN!

John Savard

[John Savard]

While waiting for the Honeywell 300 manual, I found that I missed
another group of 24-bit computers: the General Electric Compatibles-400!

They turned out to have an instruction format very similar to that of
the Control Data 1604, but here the value of 7 in the index register
field, instead of indicating an indirect address, indicated one or more
address modification words would follow the instruction.

I've updated

http://www.quadibloc.com/comp/cp0303.htm

with a note on this computer.

John Savard
http://www.quadibloc.com/index.html

[Scott Lurndal]

jsa...@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

>with a note on this computer.
>
>John Savard
>http://www.quadibloc.com/index.html

You might want to update your cp05 page. The burroughs 220 instruction format
was:

+-------------------------------------------+
| Sign| Control Digits | Opcode | Address |
| | | | | | | | | | | |
+-------------------------------------------+

(From _An Introduction to coding the Burroughs 220_, Bulletin 5019, December 1958)

The address field is also used as a constant field for some instructions.

The control digits designate special properties or variations of the instruction.

There were the following registers:
A (11 decimal digits, ten digits for the value, one for the sign)
R (11 digits), extension of A register
D (11 digits), Data register for two-operand instructions.
B (4 digits, no sign) Index register
C (10 digits, no sign) Current executing instruction is held in this register
P (4 digits, no sign) Program Counter
S (4 digits, no sign) Debug register
IB (11 digits) Buffer between core storage and ALU
E (4 digits, no sign) Address of current core access

The B register is added to the 'address' field of the instruction
iff the sign digit in the instruction is odd (1 is typically used).

The 220 also supported hardware floating point with a two-digit
exponent (excess 50) and an 8-digit mantissa.

[Jon Elson]

John Savard wrote:

> While waiting for the Honeywell 300 manual, I found that I missed
> another group of 24-bit computers: the General Electric Compatibles-400!
>
> They turned out to have an instruction format very similar to that of
> the Control Data 1604, but here the value of 7 in the index register
> field, instead of indicating an indirect address, indicated one or more
> address modification words would follow the instruction.
>

I have a Honeywell Alert here, an airborne 24-bit processor.
I've gotten as far as getting the clock running, and jamming
instructions into the memory data lines and watch the memory
address lines ripple. The core memory unit that came with it
is totally wrecked, I got it in pieces, and no documents.
I was able to get a bunch of docs on the processor from
Honeywell about 20 years ago.

The CPU is 6 multilayer boards with flat pack chips on
both sides. To eliminate connectors, the boards are
connected to the backplane by flexible PC cables, and it
opens up like a book. When assembled, there are bolts that
run through all the boards, clamping them to aluminum
plates that carry the heat to a baseplate. The power
consumption is 5 V at 25 A.

Jon

[Shmuel Metz]

In <51bde71e...@news.eternal-september.org>, on 06/16/2013

at 04:28 PM, jsa...@excxn.aNOSPAMb.cdn.invalid (John Savard) said:

>While waiting for the Honeywell 300 manual,

?

I know of the H-200, H-400, DDP-316 and DDP-516, but H-300 is one that
I've never heard of.

The article talks about the advantages of 24-bit words, but it doesn't
say compared to what. In particular, it doesn't mention the common
36-bit machines, which outside of IBM usually had addresses larger
than 15 bits.

Note that the B5500 word was only 48 bits, with no added tag bits. The
tag for numeric data and for descriptors was carved out of those 48
bits, and there were no tag bits in character data or instruction
(syllable) words. The B6x00 and B7x00, OTOH, did have tag bits in
addition to the basic 48 bits.

The article mentions the RCA 601, but doesn't discuss its most
interesting feature; like the GE 6x5, the RCA 601 had a rather
flexible indirect addressing scheme, Much more powerful than the
indirect addressing on, e.g., CDC 1604, IBM 7090.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Peter Flass]

On 6/16/2013 3:15 PM, Shmuel (Seymour J.) Metz wrote:
> In <51bde71e...@news.eternal-september.org>, on 06/16/2013
> at 04:28 PM, jsa...@excxn.aNOSPAMb.cdn.invalid (John Savard) said:
>
>> While waiting for the Honeywell 300 manual,
>
> ?
>
> I know of the H-200, H-400, DDP-316 and DDP-516, but H-300 is one that
> I've never heard of.
>
> The article talks about the advantages of 24-bit words, but it doesn't
> say compared to what.

23-bit words? ;-)

In particular, it doesn't mention the common
> 36-bit machines, which outside of IBM usually had addresses larger
> than 15 bits.

I believe the 36-bitters were larger machines (IBM and others). They
were probably comparing it to smaller computers which I suspect were
18-bits at the time, if not decimal.

--
Pete

[John Savard]

On Sun, 16 Jun 2013 15:15:01 -0400, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote, in part:

>The article talks about the advantages of 24-bit words, but it doesn't
>say compared to what.

What's nice about the 24-bit word is that it's a nice place to put an
instruction, at least before general registers became common.

Thus, look at the PDP-8 (12 bits) or the Honeywell 316 (16 bits). These
machines have short opcodes of 3 or 4 bits, and the address field is 7
bits or 9 bits - referencing only a page of memory. A "page bit" lets
you reference the current page (the one containing the instruction) or
page zero, and indirect addressing, indicated by another bit, lets you
get at other places in memory.

Machines with 32-bit, 36-bit, or 48-bit instruction words often have
fields in instructions that are not frequently used.

But a 24-bit word has just enough room for everything that's important:
6 bits for the opcode, enough to allow direct floating-point support, 15
bits for the address - which seems laughable today, but back then 32K
words was plenty of space for a good FORTRAN IV compiler - and three
bits for the address mode, enough to have more than one index register.

John Savard
http://www.quadibloc.com/index.html

[James Dow Allen]

jsa...@excxn.aNOSPAMb.cdn.invalid (John Savard) might have writ, in
news:51bf01f6...@news.eternal-september.org:

> What's nice about the 24-bit word is that it's a nice place to put an
> instruction, at least before general registers became common.

What's wrong with using variable-length instructions to get best of both
brevity and addressibility? 15/30 bits on CDC 6600 or 16/32/48 on IBM 360.
(Of course on the CDC 6600 you may need to pad with NOP's to a 60-bit
boundary. Am I the only one who hand-coded SB0 0 for a 30-bit padding No-
Op instead of letting the assembler insert TWO 15-bit NOP's which were
slower?)

Microinstructions may be more interesting. :-) Does it seem odd that the
370/145 got full advantage of its 32-bit microinstruction, while the
370/135 was happy with only 16 bits? The 370/168 had a whopping 108-bit
microinstruction (126 bits in an emulation module).

James

[Shmuel Metz]

In <kpmti2$nq9$3...@dont-email.me>, on 06/17/2013

at 08:07 AM, Peter Flass <Peter...@Yahoo.com> said:

>I believe the 36-bitters were larger machines (IBM and others).
>They were probably comparing it to smaller computers which I suspect
>were 18-bits at the time, if not decimal.

Perhaps; the smaller binary machines that I recall from the 1960s were
mostly 12, 18, 24 or 30 bits, with the medium size machines being 36
or 48 and the larger machines being 36, 48 or 60.

[Shmuel Metz]

In <XnsA1E2DA494E1...@178.63.61.175>, on 06/17/2013

at 02:27 PM, James Dow Allen <gm...@jamesdowallen.nospam> said:

>Microinstructions may be more interesting. :-) Does it seem odd
>that the 370/145 got full advantage of its 32-bit microinstruction,
>while the 370/135 was happy with only 16 bits?

No, it seems predictable that you would widen the microinstruction
when you want more speed.

[John Savard]

On Mon, 17 Jun 2013 14:27:31 +0000 (UTC), James Dow Allen
<gm...@jamesdowallen.nospam> wrote, in part:

>What's wrong with using variable-length instructions to get best of both
>brevity and addressibility? 15/30 bits on CDC 6600 or 16/32/48 on IBM 360.

There's nothing wrong with that. The System/360 is a beautiful
architecture.

But when looking at classic single-address machines, from the 7090 on
down to the PDP-8, the 24-bit instruction word just happens to be, in my
opinion, a "sweet spot".

>Microinstructions may be more interesting. :-) Does it seem odd that the
>370/145 got full advantage of its 32-bit microinstruction, while the
>370/135 was happy with only 16 bits? The 370/168 had a whopping 108-bit
>microinstruction (126 bits in an emulation module).

That's not odd; it's a direct consequence of the 360/85, the 370/165,
the 370/168, and the 3033 all being designed to be IBM's
highest-performance microcoded computer, so each microinstruction had to
do more.

John Savard
http://www.quadibloc.com/index.html

[James Dow Allen]

James Dow Allen <gm...@jamesdowallen.nospam> might have writ, in
news:XnsA1E2DA494E1...@178.63.61.175:

> Does it seem odd that the
> 370/145 got full advantage of its 32-bit microinstruction, while the

> 370/135 was happy with only 16 bits?...

I should have written "interesting" rather than "odd." The microcode
shared main memory in each case -- that's why the sizes were powers of 2.
The 135 bus widths were mostly 16 bits, and so was the microinstruction.
Similarly the 145 was 32 bits almost everywhere.

The 145 might have been almost twice as fast as the 135 overall, BUT this
was mainly due to its wider data busses and faster cycles, not its wider
instruction. Does bitsavers have any microcode preserved? If so, I think
it can be demonstrated that the 135's narrower instruction word didn't pose
major performance degradation.


Re: bitsavers. I see the FE summary for the machine (370/145) I learned
best:
http://bitsavers.trailing-edge.com/pdf/ibm/370/fe/3145/SY24-3581-1_3145
_Processing_Unit_Theory-Maintenance_Oct71.pdf

That's a 1971 document before DAT, even though IIRC no 145's without DAT
were ever shipped. More importantly, that pdf is missing the "second-
level diagrams" -- a wonderful schematic of several pages much more
detailed than an ordinary block diagram, yet not quite at the detailed
level of circuit schematic.

James

[Peter Flass]

On 6/18/2013 3:04 AM, James Dow Allen wrote:
> James Dow Allen <gm...@jamesdowallen.nospam> might have writ, in
> news:XnsA1E2DA494E1...@178.63.61.175:
>
>> Does it seem odd that the
>> 370/145 got full advantage of its 32-bit microinstruction, while the
>> 370/135 was happy with only 16 bits?...
>
> I should have written "interesting" rather than "odd." The microcode
> shared main memory in each case -- that's why the sizes were powers of 2.
> The 135 bus widths were mostly 16 bits, and so was the microinstruction.
> Similarly the 145 was 32 bits almost everywhere.
>
> The 145 might have been almost twice as fast as the 135 overall, BUT this
> was mainly due to its wider data busses and faster cycles, not its wider
> instruction. Does bitsavers have any microcode preserved? If so, I think
> it can be demonstrated that the 135's narrower instruction word didn't pose
> major performance degradation.

It would be nice to see. They have a couple of IBM references on
microcode (which I don't have ready to hand). My understanding was that
each machine had a unique microinstruction set - seemed wasteful until I
happened to think that the actual bare metal was so different on most
machines that the microcode would have little commonality.

I would suspect that machines with microinstruction size 32 bits or less
would be vertical microcode and the longer instructions would be horizontal.


--
Pete

[Nick Spalding]

James Dow Allen wrote, in <XnsA1E2DA494E1...@178.63.61.175>
on Mon, 17 Jun 2013 14:27:31 +0000 (UTC):

Even the humble 360/30 had 60-bit microinstructions.
<http://www.glennsmuseum.com/ibm/pics/capacitor_ros.jpg>
--
Nick Spalding

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> It would be nice to see. They have a couple of IBM references on
> microcode (which I don't have ready to hand). My understanding was
> that each machine had a unique microinstruction set - seemed wasteful
> until I happened to think that the actual bare metal was so different
> on most machines that the microcode would have little commonality.
>
> I would suspect that machines with microinstruction size 32 bits or
> less would be vertical microcode and the longer instructions would be
> horizontal.

i.e. that was the justification behind the "Fort Knox" and other
programs around 79/80 to migrate the vast number of internal
microprocessors (low/mid range 370s, controllers, followon to s/38) to
801/risc (mostly Iliad chips). For various reasons all the programs
floundered and most programs returned to traditional CISC chips (and you
find some number of the 801/risc engineers leaving and showing up at
risc efforts at other vendors).

One of these programs would have used 801/risc for the followon to the
4341, ... I contributed to white paper that justified doing a CISC
(rather than RISC) for the 4381. The 801/risc scenario for 370 was that
everything was still implemented all in microcode ... the white paper
showed that CISC chip technology was advancing to the point that a
significant amount of 370 instructions could be directly implemented in
hardware ... gaining a significant performance advantage (rather than
loosing the 10:1 factor doing emulation). The Iliad 801/risc chips would
still have had all 370 done in (801/risc) programming.

misc. past posts mentioning 801, risc, iliad, fort knox, romp, rios,
power, etc
http://www.garlic.com/~lynn/subtopic.html#801
and some old email
http://www.garlic.com/~lynn/lhwemail.html#801

the difficulty/cost of programming horizontal microcode contributed to
switching from horizontal microcode for the 3830 disk controller (3330,
3340, 3350 disks) to vertical microcode for the 3880 disk controller
(3380). The issue was that the 3880 disk controller was going to have
significant more function than 3830. However, the cisc chip chosen for
the 3880 was a really inexpensive and slow Jib-prime. Except for a
special hardware data transfer path added for 3mbyte/sec transfer, all
the control functions took significantly longer time on 3880 than 3830
(low level engineers in the division was predicting this all along).

legacy mainframe channel paradigm is serialized half-duplex ... during
which time the channel is "busy". POK 3090 product had assumed that the
3880 channel-busy overhead was going to be capareable to the 3830
... however, when they discovered that 3880 channel busy overhead was
significantly larger ... they realized that they would have to
significantly increase the number of 3090 channels in order to achieve
aggregate system throughput objectives. The additional channels required
an additional TCM (which was not an insignificant cost) and there were
statements about charging off the increased 3090 manufacturing costs
against the 3880 controller group. IBM Marketing then respins the
massive number of 3090 channels as a benefit (rather than compensation
for the really large channel busy overhead for 3880 operations). some
past posts getting to play disk engineer in bldgs. 14&15
http://www.garlic.com/~lynn/subtopic.html#disk

I've pontificated that this legacy channel paradigm lingers on in the
enormous overhead for mainframe FICON (layer built on industry standard
that enormously cuts the throughput compared to the underlying native
FCS). recent mention of FICON:
http://www.garlic.com/~lynn/2013g.html#2 A Complete History Of Mainframe Computing
http://www.garlic.com/~lynn/2013g.html#4 A Complete History Of Mainframe Computing
http://www.garlic.com/~lynn/2013g.html#14 Tech Time Warp of the Week: The 50-Pound Portable PC, 1977
http://www.garlic.com/~lynn/2013g.html#23 Old data storage or data base
http://www.garlic.com/~lynn/2013g.html#49 A Complete History Of Mainframe Computing
http://www.garlic.com/~lynn/2013g.html#85 Old data storage or data base
http://www.garlic.com/~lynn/2013h.html#3 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2013h.html#40 The Mainframe is "Alive and Kicking"
http://www.garlic.com/~lynn/2013h.html#42 The Mainframe is "Alive and Kicking"
http://www.garlic.com/~lynn/2013h.html#79 Why does IBM keep saying things like this:
http://www.garlic.com/~lynn/2013h.html#80 Minicomputer Pricing


--
virtualization experience starting Jan1968, online at home since Mar1970

[John Savard]

On Tue, 18 Jun 2013 13:27:06 +0100, Nick Spalding <spal...@iol.ie>
wrote, in part:

>Even the humble 360/30 had 60-bit microinstructions.
><http://www.glennsmuseum.com/ibm/pics/capacitor_ros.jpg>

IIRC, that 60-bit ROS word actually contained more than one
microinstruction.

John Savard
http://www.quadibloc.com/index.html

[Peter Flass]

On 6/18/2013 11:01 AM, Anne & Lynn Wheeler wrote:
>
> the difficulty/cost of programming horizontal microcode contributed to
> switching from horizontal microcode for the 3830 disk controller (3330,
> 3340, 3350 disks) to vertical microcode for the 3880 disk controller
> (3380). The issue was that the 3880 disk controller was going to have
> significant more function than 3830. However, the cisc chip chosen for
> the 3880 was a really inexpensive and slow Jib-prime.

Google turns up almost nothing on Jib-prime. Did you happen to save any
doc?


--
Pete

[Lawrence Wilkinson]

On Tue, 18 Jun 2013 18:13:47 +0000, John Savard wrote:

> On Tue, 18 Jun 2013 13:27:06 +0100, Nick Spalding <spal...@iol.ie>
> wrote, in part:
>
>>Even the humble 360/30 had 60-bit microinstructions.
>><http://www.glennsmuseum.com/ibm/pics/capacitor_ros.jpg>
>
> IIRC, that 60-bit ROS word actually contained more than one
> microinstruction.

No, only one, and fairly horizontal. A few fields had multiple uses.

The first few columns of the card image cited above are just a position
code. From that one can tell that the the top row on that card is
address 65F which is part of the multiplexer channel handling.

>
> John Savard http://www.quadibloc.com/index.html

--
Lawrence Wilkinson lawr...@ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> Google turns up almost nothing on Jib-prime. Did you happen to save
> any doc?

re:
http://www.garlic.com/~lynn/2013h.html#86 By Any Other Name

don't find anything more on JIB' ... some on microcode development
system ... used for developing JIB' code on 370
http://www.garlic.com/~lynn/2006v.html#17
with these old email about using 370 for software development (aka
microcode development system)
http://www.garlic.com/~lynn/2006v.html#email791010
http://www.garlic.com/~lynn/2006v.html#email791010b
http://www.garlic.com/~lynn/2006v.html#email791010c

above mentions have difficult time moving MDS from MVS to CMS (in part
because using various MVS features not supported by CMS).

other email mentioning mds
http://www.garlic.com/~lynn/2006v.html#email800717
in this post
http://www.garlic.com/~lynn/2006v.html#19

http://www.garlic.com/~lynn/2006v.html#email800624
in this post
http://www.garlic.com/~lynn/2006v.html#23

finally instead of changing application code to work with cms features
... they wrote 12k code to add simulation for the unsupported MVS
features to CMS (there use to be joke about the 64k-byte os/360
simulation in cms was a lot more efficient than the 8mbyte os/360
simulation in MVS)

http://www.garlic.com/~lynn/2006v.html#email800903
in this post
http://www.garlic.com/~lynn/2006v.html#25

http://www.garlic.com/~lynn/2006p.html#email810128
in this post
http://www.garlic.com/~lynn/2006p.html#40

JIB' was done at los gatos lab ... designed to management requirements
... so it can't be said that LSG is to blame (besides getting to play
engineer in bldg14&15, I got to play in LSG/bldg29)

LSG also did "blue iliad" ... first 32bit risc/801 chip ... really
large and never got beyond sampling. however, LSG pioneered use of
scanning electronic microscope in chip debugging. misc. old email
mentioning 801/risc ... including iliad and blue iliad references
http://www.garlic.com/~lynn/lhwemail.html#801

I had several offices and labs in LSG (even tho I was in research and
had office in research bldg). LSG also did the LSM (Los Gatos State
Machine ... although in publication LSM became logic simulation
machine). It was one of the few logic simulation machines that included
clock support ... most assumed synchronous clock. Clock support allowed
support of chips w/o global synchronous clock as well as digital chips
with analog circuits (i.e. thinfilm r/w disk heads).

HSDT included 4.5m TDMA satellite dish in LSG back parking lot and a 7m
TDMA satellite dish in Austin next to the AWD engineering bldg (had
transponder on SBS4 which went up on 41D ... I was invited to launch
party at the cape). High-speed link between Austin and the LSM in Los
Gatos is credited with helping bring in the RIOS (aka rs/6000) chipset a
year early. misc. past posts mentioning HSDT
http://www.garlic.com/~lynn/subnetwork.html#hsdt

past posts mentioning LSM
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
http://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
http://www.garlic.com/~lynn/2007l.html#53 Drums: Memory or Peripheral?
http://www.garlic.com/~lynn/2007m.html#58 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007m.html#61 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007n.html#22 What if phone company had developed Internet?
http://www.garlic.com/~lynn/2007o.html#67 1401 simulator for OS/360
http://www.garlic.com/~lynn/2007o.html#68 CA to IBM TCP Conversion
http://www.garlic.com/~lynn/2008c.html#68 Toyota Beats GM in Global Production
http://www.garlic.com/~lynn/2009k.html#75 Disksize history question
http://www.garlic.com/~lynn/2009m.html#63 What happened to computer architecture (and comp.arch?)
http://www.garlic.com/~lynn/2010c.html#71 using an FPGA to emulate a vintage computer
http://www.garlic.com/~lynn/2010f.html#83 Notes on two presentations by Gordon Bell ca. 1998
http://www.garlic.com/~lynn/2010m.html#52 Basic question about CPU instructions
http://www.garlic.com/~lynn/2010o.html#50 The Credit Card Criminals Are Getting Crafty

[Shmuel Metz]

In <kpphat$o0r$1...@dont-email.me>, on 06/18/2013

at 07:56 AM, Peter Flass <Peter...@Yahoo.com> said:

>It would be nice to see. They have a couple of IBM references on
>microcode (which I don't have ready to hand). My understanding was
>that each machine had a unique microinstruction set

That was true initially, but AFAIK the 360/22, 360/67, 370/148,
370/158, 9020, 370/165, 370/168, 3031, 3032 and 3033 all reused an
older microinstruction repertoire.

[Shmuel Metz]

In <XnsA1E38F37EB9...@178.63.61.175>, on 06/18/2013

at 07:04 AM, James Dow Allen <gm...@jamesdowallen.nospam> said:

>Re: bitsavers. I see the FE summary for the machine (370/145) I
>learned best:
> http://bitsavers.trailing-edge.com/pdf/ibm/370/fe/3145/SY24-3581-1_3145
>_Processing_Unit_Theory-Maintenance_Oct71.pdf

>That's a 1971 document before DAT,

FSVO. Read OS DOS COMPATIBILITY, especially p. 2-118, and draw your
own conclusions.

[Jon Elson]

John Savard wrote:


> That's not odd; it's a direct consequence of the 360/85, the 370/165,
> the 370/168, and the 3033 all being designed to be IBM's
> highest-performance microcoded computer, so each microinstruction had to
> do more.

This emulation thing never fully made sense to me.
Yes, if you were replacing a 1401 with a 360/30, the /30
was SOOOO slow that the only hope of keeping up with the
card reader, or especially tape, was to emulate in microcode.

But, for bigger machines like the /50 and /65, I really don't
see the point. An emulator written in 360 BAL would probably
run nearly as fast, and could be totally compatible with OS/360,
and thus be a lot more flexible. We laughably had the 7090
emulator on our 360/65 because some stupid accounting program
was in 7090 object format, the source had been lost, and
nobody trusted they could re-write the program.

Especially on 370 models, the justification for microcode
emulators seemed even more ridiculous.

I never understood how the microcode emulators worked with
respect to multiprogramming and interface to the OS. So,
I could be way off base on this.

Jon

[Jon Elson]

James Dow Allen wrote:


> The 145 might have been almost twice as fast as the 135 overall, BUT this
> was mainly due to its wider data busses and faster cycles, not its wider
> instruction. Does bitsavers have any microcode preserved? If so, I think
> it can be demonstrated that the 135's narrower instruction word didn't
> pose major performance degradation.

Major performance degradation? These machines were DOGS! From the
360/30 with a totally laughable 40 K instructions/second, as long as
all programs used only RR instructions, to the 370/145 which was a bit
faster with MST logic, but still ran just a few hundred K
instructions/second (.36 or .46 mips depending on version).
For the first machine with semiconductor memory, it ought to
have done better. It did have pretty good I/O throughput, which
of course was IBM's strong suit. We had TSO running on a 3145,
and they got FOUR users to tie up the whole machine! Geez, wasn't
just a few years later we had 25 users on a VAX 11/780 with no
problems. (Note: we NEVER, EVER bought a 360 or 370 new, and often
bought them a bit too late, when they were past obsolete.)

Jon

[Quadibloc]

On Tuesday, June 18, 2013 12:13:47 PM UTC-6, John Savard wrote:

> IIRC, that 60-bit ROS word actually contained more than one
> microinstruction.

Now I know the place to check: Microprogramming, Principles and Practices by Samir S. Husson - as I don't have immediate access to my copy, I had forgotten the name of the book.

[Anne & Lynn Wheeler]

Jon Elson <jme...@wustl.edu> writes:
> Major performance degradation? These machines were DOGS! From the
> 360/30 with a totally laughable 40 K instructions/second, as long as
> all programs used only RR instructions, to the 370/145 which was a bit
> faster with MST logic, but still ran just a few hundred K
> instructions/second (.36 or .46 mips depending on version).
> For the first machine with semiconductor memory, it ought to
> have done better. It did have pretty good I/O throughput, which
> of course was IBM's strong suit. We had TSO running on a 3145,
> and they got FOUR users to tie up the whole machine! Geez, wasn't
> just a few years later we had 25 users on a VAX 11/780 with no
> problems. (Note: we NEVER, EVER bought a 360 or 370 new, and often
> bought them a bit too late, when they were past obsolete.)

Note that VM370 typically supported ten times as many users as TSO (on
same hardware), with much better interactive response and throughput ...
and much better graceful degradation as workload increased.

vax-11/780 supposedly was considered closer in performance to 4341
than 145.

370/145 Announced 23Sep1970
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3145.html
370/148 Announced 30Jun1976
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3148.html
vax-11/780 25Oct1977
http://en.wikipedia.org/wiki/VAX-11
4341 Announced 30Jan1979
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4341.html

there was a lot of simplification in the morph from cp/67 to vm/370
... dropping a lot of performance enhancements I had done. I did some
work to re-introduce some instruction pathlength optimization that was
re-introduced in vm/370 release 2. However, much of cp/67 to vm/370
migration wasn't done until after release 2 ... for csc/vm internal
use. Old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

some of csc/vm was shipped to customers as part of vm/370 release 3.
other parts of csc/vm was shipped to customers as part of separate
charged-for addon to vm/370 release 3.

I also got sucked into working on ECPS for 138/148. Engines avg. 10
native instructions for every 370 instruction. 370 instructions dropped
into native nearly on 1:1 basis (for 10:1 performance improvement). Was
told that the machines had 6kbytes for ECPS instructions, so objective
was to identify that highest used 6kbytes of instructions. This old post
has some of the kernel pathlength analysis (highest 6kbytes accounted
for 79.55% of kernel cpu time). ECPS shipped for 138/148 (late in
release 3 cycle)
http://www.garlic.com/~lynn/94.html#21

recent post mentioning head of POK (high-end mainframe) considered
one of the biggest contributors to vax/vms:
http://www.garlic.com/~lynn/2013i.html#5

i.e. head of POK convinced corporate to kill-off vm370 product, shutdown
the burlington mall development group and transfer all the people to POK
to support mvs/xa (or otherwise mvs/xa wouldn't make ship schedule in
the 80s). objective was to not tell the group until just before shutdown
(to minimize number of people that would escape), however it managed to
leak a couple months early ... allowing many developers to escape (some
number going over to dec). endicott eventually managed to save the vm370
product mission ... but had to reconstitute a development group from
scratch. share user group had some number of comments about code quality
on online discussion group (originated aug1976) ... archived here
http://vm.mairist.edu/~vmshare/

[Jon Elson]

Nick Spalding wrote:


> Even the humble 360/30 had 60-bit microinstructions.
> <http://www.glennsmuseum.com/ibm/pics/capacitor_ros.jpg>

Easy to make wide words when you are punching your code into plastic
punch cards. All it takes electronically is some word line drivers
and sense amps.

Jon

[Shmuel Metz]

In <BKGdnf0mJsWQNlXM...@giganews.com>, on 06/24/2013

at 03:32 PM, Jon Elson <jme...@wustl.edu> said:

>We had TSO running on a 3145,
>and they got FOUR users to tie up the whole machine!

That may have had more to do with the memory size and the DASD
configuration than with the CPU speed.

[Shmuel Metz]

In <CJqdnRA1dPWbNFXM...@giganews.com>, on 06/24/2013

at 03:24 PM, Jon Elson <jme...@wustl.edu> said:

>But, for bigger machines like the /50 and /65, I really don't see
>the point. An emulator written in 360 BAL would probably run
>nearly as fast,

Well, other than the fact that BAL was BPS only, the 360/65 didn't
have a 1401 emulator, so a S/360 level simulator would have been the
only option.

>and could be totally compatible with OS/360,

The compatability features for the 360/85 and all models of the S/370
were designed to be usable under OS/360 and OS/VS. Some earlier
emulator programs were able to run under DOS/360.

>Especially on 370 models, the justification for microcode emulators
>seemed even more ridiculous.

CPU time was expensive. If you had a lot of 14xx or 70xx work, the
emulator features could save a lot of time.

>I never understood how the microcode emulators worked with respect
>to multiprogramming and interface to the OS. So, I could be way
>off base on this.

There were special instructions; you used the same emulator program
even when the underlying microcode was different.

[John Levine]

>>We had TSO running on a 3145,
>>and they got FOUR users to tie up the whole machine!
>
>That may have had more to do with the memory size and the DASD
>configuration than with the CPU speed.

At Princeton, I don't think they ever got more than a dozen users
running under TSS on a 360/67.

The problem wasn't the hardware, it was bloated code and a virtual
memory system that predated the idea of a working set.

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Anne & Lynn Wheeler]

John Levine <jo...@iecc.com> writes:
> At Princeton, I don't think they ever got more than a dozen users
> running under TSS on a 360/67.
>
> The problem wasn't the hardware, it was bloated code and a virtual
> memory system that predated the idea of a working set.

re:
http://www.garlic.com/~lynn/2013i.html#29 By Any Other Name

undergraduate in late 60s, got to play with 768kbyte 360/67 on weekends
(ran as 360/65 with os/360 during the week) with cp67 ... trading off
some when IBM SE played with tss/360.

we did simulated fortran edit, compile, and execute script ... tss/360
script running 4 simulated users with the script had worse response and
throughput than cp/67-cms had running 35 simulated uses. this had some
of the pathlength rewrite that i had done by late summer 1968 ... but
not all ... part of SHARE presentation i did late summer 1968
http://www.garlic.com/~lynn/94.html#18

release 1 of cp67 didn't do lru page replacement with references bits
and didn't have page thrashing control. Lincoln labs did a fixed
configuration page thrashing controls ... which was run for above.

I then did dynamic adaptive page thrashing controls, (global) clock-like
page replacement with reference bits and dynamic adaptive resource
management (achieved similar objective to working set acm paper
published in 1968). I also then did order seek queueing for queued disk
requests and chained requires for queued page requests on drums or same
head position on disk. All significantly further improved throughput and
response of "large" number of cms users.

tss/360 looking for bright spot ... did some benchmarks with 1mbyte
360/67 single processor and 2mbyte 360/67 dual processor ... with the
2mbyte dual processor having 3.8 times the throughput of single
processor. The spin was that tss/360 was the most advanced
multiprocessor operating system since it could get nearly four times the
throughput with twice the resources. it actually turns out that the
tss/360 kernel was so bloated ... needed much more than 1mbyte real
storage for any significant resources available for applications.

much later in the early 80s ... there was co-worker of jim gray's at
tandem trying to get his stanford phd on clock/global lru page
replacement ... and was being fiercely fought by the forces behind the
1968 acm working set article (which turned out to also be local lru page
replacement). Jim knew that I had done a lot of work as undergraduate in
the 60s and asked me to help with his co-worker.

It turns out my stuff was running in the standard cp67 release 3
... including the 768kbyte single process 360/67 (104 pages for paging
after fixed kernel requirements) at the cambridge science center. Thea
Grenoble Science Center had 1mbyte 360/67 (154 pages for paging after
fixed kernel requirements). Grenoble then modified the cp67 system to
implement what was described in the 68 acm working set paper. That
grenoble system with 30-35 users had about the same response and
throughput as the cambridge system running similar workloads with 70-75
users (half as many users and 50% more real storage for paging). old post
http://www.garlic.com/~lynn/94.html#1

past posts discussing Jim's request
http://www.garlic.com/~lynn/2006w.html#46
with part of the response
http://www.garlic.com/~lynn/2006w.html#email821019

past posts mentioning the paging work
http://www.garlic.com/~lynn/subtopic.html#clock

Jim had originally made the request at the 14-16Dec81 SIGOPS conference
... but research management wouldn't let me send a response until nearly
a year later (hopefully it wasn't management taking sides in the
academic dispute ... but trying to punish me because they blamed me for
online computer conferencing on the internal network in the late 70s and
early 80s).

trivia: the thesis advisor later became stanford president

[Nick Spalding]

Jon Elson wrote, in <-NKdnejhSPQcV1XM...@giganews.com>
on Mon, 24 Jun 2013 17:46:53 -0500:

I still have one of those cards that I took out of a /30 in 1967. It is
a tiny bit off-punch and some of the holes had a sliver of metal a few
thou wide on one edge. Every now and again that would cause a bit to
pick and the machine stopped with red lights blazing. Unfortunately by
then it had taken a machine-check interrupt and the location of the
problem card had been lost. I patched on a jumper to stop the clock
dead when the original parity error occurred and the location became
visible. A bit of careful work with a keypunch and a fresh card and the
problem was solved.
--
Nick Spalding

[Shmuel Metz]

In <kqb2ej$1tat$2...@leila.iecc.com>, on 06/25/2013

at 03:22 AM, John Levine <jo...@iecc.com> said:

>At Princeton, I don't think they ever got more than a dozen users
>running under TSS on a 360/67.

With or without LCS?

[Peter Flass]

On 6/24/2013 5:58 PM, Anne & Lynn Wheeler wrote:
>
> Jon Elson <jme...@wustl.edu> writes:
>> Major performance degradation? These machines were DOGS! From the
>> 360/30 with a totally laughable 40 K instructions/second, as long as
>> all programs used only RR instructions, to the 370/145 which was a bit
>> faster with MST logic, but still ran just a few hundred K
>> instructions/second (.36 or .46 mips depending on version).
>> For the first machine with semiconductor memory, it ought to
>> have done better. It did have pretty good I/O throughput, which
>> of course was IBM's strong suit. We had TSO running on a 3145,
>> and they got FOUR users to tie up the whole machine! Geez, wasn't
>> just a few years later we had 25 users on a VAX 11/780 with no
>> problems. (Note: we NEVER, EVER bought a 360 or 370 new, and often
>> bought them a bit too late, when they were past obsolete.)
>
> Note that VM370 typically supported ten times as many users as TSO (on
> same hardware), with much better interactive response and throughput ...
> and much better graceful degradation as workload increased.

Never confuse bad hardware with lousy software, although the /145
running MVS probably had both. I never used one.

--
Pete