Microcode? 
Author Message
 Microcode?

I think that you have the 360s backwards:  I think that most were
hardwire and only one or two were micro-coded (the 67?).

I believe that all of the newer machines are microcoded, with different
levels of microcode.  For example, the G6 came with the IEEE floating
point instructions, but they could be added to the G5 with an EC.

Lloyd


Quote:
>x-no-archive: yes

>Did all S/360 models use microcode?  I seem to recall reading that
>one of the high end models (75???) did NOT use microcode, but was
>fully hard wired in order to give it improved performance.

>Is microcode still used on today's S/390?  Is it just one level
>or multiple levels as in the AS/400?



Sun, 27 Jun 2004 09:17:02 GMT  
 Microcode?

Quote:

>I think that you have the 360s backwards:  I think that most were
>hardwire and only one or two were micro-coded (the 67?).
>I believe that all of the newer machines are microcoded, with different
>levels of microcode.  For example, the G6 came with the IEEE floating
>point instructions, but they could be added to the G5 with an EC.

Microcode means different things to different people.

The low-end 360's used what is called vertical microcode.
They had a small amount of real hardware and many microinstructions
per real instruction.  For example, the 360/30 and 360/40 have 8
bit ALU's.  Yes, we call it a 32 bit machine, but it can only add
8 bits at a time.  

The high end 360's were hardwired.  

But later what is called horizontal microcode became more popular.  
In that case, there is enough hardware, but the hardware design
is more regular and the complexity is in microcode, many bits wide.  
Only a small number of very large micro- instructions are
executed per real instruction.

Many machines now are done this way.  The design process is more
efficient and machines can run just as fast.  

-- glen



Sun, 27 Jun 2004 16:28:11 GMT  
 Microcode?

Quote:
>I think that you have the 360s backwards:  I think that most were
>hardwire and only one or two were micro-coded (the 67?).

I am pretty certain that all the original ones were microcoded, though to
varying extents: for example the Model 30 had an 1-byte bus and adder, whereas
the 75 had 4-byte bus and adder, so many instructions were effectively
one mcrocode instruction. The 91, I believe, was hard-wired, but that wasn't
one of the original range.
James Davenport


Sun, 27 Jun 2004 20:32:28 GMT  
 Microcode?


Quote:

> Did all S/360 models use microcode?  I seem to recall reading that
> one of the high end models (75???) did NOT use microcode, but was
> fully hard wired in order to give it improved performance.

The original IBM/360s (30, 40, 50, 60, and 70) had four
microcoded models, and one hardwired model - the 70.
For purists, note that either the 60 or 70 was never shipped
(I don't remember which.) The models in the field were the 65
and the 75.

Also, the 360/44 and 360/91 were hard-wired. All other
models I know of had some form of microcode.

Quote:
> Is microcode still used on today's S/390?  Is it just one level
> or multiple levels as in the AS/400?

Depends on the architecture.

John Roth



Mon, 28 Jun 2004 02:46:28 GMT  
 Microcode?


Quote:

> >I think that you have the 360s backwards:  I think that most were
> >hardwire and only one or two were micro-coded (the 67?).

> >I believe that all of the newer machines are microcoded, with
different
> >levels of microcode.  For example, the G6 came with the IEEE floating
> >point instructions, but they could be added to the G5 with an EC.

> Microcode means different things to different people.

> The low-end 360's used what is called vertical microcode.
> They had a small amount of real hardware and many microinstructions
> per real instruction.  For example, the 360/30 and 360/40 have 8
> bit ALU's.  Yes, we call it a 32 bit machine, but it can only add
> 8 bits at a time.

DING! The 360/40 had a 16 bit ALU (which expanded to 20 if
you had one of the 14xx emulation features installed.)

They also didn't execute that many microinstructions per
memory cycle - usually 3 or 4, and the machines executed
instructions fairly close to the memory cycle limits. They were
also horizontal microcode - the words were fairly wide (80 or more bits,
depending on the processor) and had multiple fields.

John Roth



Mon, 28 Jun 2004 02:51:06 GMT  
 Microcode?


Quote:
> In the referenced article, "Lloyd Fuller"

> >I think that you have the 360s backwards:  I think that most were
> >hardwire and only one or two were micro-coded (the 67?).
> I am pretty certain that all the original ones were microcoded, though
to
> varying extents: for example the Model 30 had an 1-byte bus and adder,
whereas
> the 75 had 4-byte bus and adder

The 70 and 75 were hard-wired, and had an 8-byte bus and adder.
The 60 and 65 were microcoded, but also had an 8-byte bus and adder. The
other difference was that the 75 had a three address adder so that it
could
add a base, displacement and index in one operation. All other models
slowed
down if you accidentally put the base register in the index position.
(IBM
fixed that problem with the /370.

John Roth



Mon, 28 Jun 2004 02:54:10 GMT  
 Microcode?


Quote:

> Thanks for the responses.

> Could someone explain the difference between "vertical" and
> "horizontal" microcode as used on S/360?

> Also, for today's S/390 machines, isn't everything standard now,
> that is, all models can do all functions?  (Although obviously the
> low-end models would need more wallclock time to perform an operation
> than the high-end models.)  In other words, don't all machines have
the
> universal instruction set for S/390?

Horizontal microcode contains a field for all of the various
gates and registers in the part of the system it controls, usually
dozens of fields. It controls a lot of different functions on each
machine cycle.

Vertical microcode is more like regular instructions; it's does
relatively little on each cycle, and takes several cycles to get
anything done.

In general, horizontal microcode is used when the actual
core of the machine is microprogrammed. Vertical microcode
is used when the core of the system is hard wired, and the
vendor needs to implement a number of very complicated
instructions that it's not reasonable to hard wire.

In general, yes. All current machines pretty much have the
same instruction set. The variations are in which operating
systems they support - there are special 'assist' instructions
that are needed to run MVS, and a different set to run
VM. IBM will sell you a z-series machine to run VM/Linux
without the ability to run MVS for a cut rate. It's quite
popular (or so I hear) with hosting companies to replace
server farms.

IBM learned several decades ago that there isn't anything
like a 'pure' commercial workload, or a 'pure' scientific
workload. The idea that there was came from its 1950's
mainframe series, which was divided into commercial
machines (705, 7080, 14xx, 650) and scientific machines
(702, 704, 7040, 709, 7090, 7094.) They dropped the
idea quite a while ago.

John Roth



Mon, 28 Jun 2004 10:46:13 GMT  
 Microcode?

And that's why some of still write, for example -

          LA    R1,8(,R1)

instead of -

          LA    R1,8(R1)

(I really had to *force* myself not to code the comma just then)

Tom Grieve

Quote:

>The other difference was that the 75 had a three address adder so that it
>could add a base, displacement and index in one operation. All other models slowed down if you accidentally put the base register in the index position. (IBM fixed that problem with the /370.

>John Roth



Mon, 28 Jun 2004 15:35:07 GMT  
 Microcode?
Tom,

The concept of dropping the index (read: inserting the comma) has taken on
new meaning since the advent of ESA.


wrote on 01/09/2002 23:35:

Quote:

> And that's why some of still write, for example -

> LA    R1,8(,R1)

> instead of -

> LA    R1,8(R1)

> (I really had to *force* myself not to code the comma just then)

> Tom Grieve


>> The other difference was that the 75 had a three address adder so that it
>> could add a base, displacement and index in one operation. All other models
>> slowed down if you accidentally put the base register in the index position.
>> (IBM fixed that problem with the /370.

>> John Roth



Tue, 29 Jun 2004 00:09:14 GMT  
 Microcode?

Bill,
Don't tease - tell us why!

Tom Grieve

Quote:

>Tom,

>The concept of dropping the index (read: inserting the comma) has taken on new meaning since the advent of ESA.



Tue, 29 Jun 2004 15:46:02 GMT  
 Microcode?
Don't know about every model, but the 360-30 had "CROS",
"Capacitor Read Only Storage".  The capacitors were arrayed on
a film in standard 80 col card format.  The cards were arrayed
in a cage.  The microcode could be redone using a key-punch,

Don't know the details, but several machines were reprogrammed to
serve as communication controllers.


Quote:
> I think that you have the 360s backwards:  I think that most were
> hardwire and only one or two were micro-coded (the 67?).

> I believe that all of the newer machines are microcoded, with different
> levels of microcode.  For example, the G6 came with the IEEE floating
> point instructions, but they could be added to the G5 with an EC.

> Lloyd


> >x-no-archive: yes

> >Did all S/360 models use microcode?  I seem to recall reading that
> >one of the high end models (75???) did NOT use microcode, but was
> >fully hard wired in order to give it improved performance.

> >Is microcode still used on today's S/390?  Is it just one level
> >or multiple levels as in the AS/400?



Tue, 29 Jun 2004 20:02:31 GMT  
 Microcode?

Quote:

> Bill,
> Don't tease - tell us why!

> Tom Grieve


> >Tom,

> >The concept of dropping the index (read: inserting the comma) has taken on new meaning since the advent of ESA.

In AR mode, a non-zero base register also uses the associated access
register for address resolution. A non-zero index register with a zero
base always implies the primary address space.

--
Robert Ngan
CSC Financial Services Group



Tue, 29 Jun 2004 19:53:06 GMT  
 Microcode?

Quote:

> I think that you have the 360s backwards:  I think that most were
> hardwire and only one or two were micro-coded (the 67?).

> I believe that all of the newer machines are microcoded, with different
> levels of microcode.  For example, the G6 came with the IEEE floating
> point instructions, but they could be added to the G5 with an EC.

all of the 360 machines were m'coded except the 75 which was
essentially a hired-wired 65.

the models were 30, 40, 50, 60, 62, 70

before shipment to customers, the 60, 62, & 70 were renamed 65, 67, &
75. I believe that the original model numbers were going to have 1mic
memory and the change was to faster memory technology at 750nsec.

the 62/67 was effectively 60/65 with virtual memory & 32bit virtual
addressing option. the other major change in the 67 was for SMP. the
65 SMP was effectively two 65s with memory ganged together so both
processors had common addressing ... but still totally independent I/O
and other facilities. The 67 SMP had what was called a "channel
controller" ... which was a configuration box for both memory boxes and
I/O channels (allowing memory boxes & channels to be switched on, off,
shared, dedicated). The 67 SMP had control registers that "sensed" the
settings in the channel controller and there was a special RPQ that
allowed the processor to change the channel controller switch settings
by changing the corresponding bits in the control registers.
http://www.garlic.com/~lynn/2001c.html#15
http://www.garlic.com/~lynn/2001.html#69
http://www.garlic.com/~lynn/2001.html#71

In addition the 67 duplex (two-processor) had tri-ported memory
... independent paths for channels and the two processors. The
tri-ported memory introduced additional latency. A "half-duplex" '67
had about 10% slower memory cycle than a "simplex" '67 ... however
under heavy I/O load, a "half-duplex" 67 had higher thruput than a
"simplex" '67 because of the reduction in memory bus contention
between processor and I/O.
http://www.garlic.com/~lynn/98.html#23
http://www.garlic.com/~lynn/2001j.html#3
http://www.garlic.com/~lynn/2001j.html#14

The work at CSC with on fine-grain locking for '67 SMP led to the
compare&swap instruction in the 370 (compare&swap was chosen because
the mnemonic was the person's initials that did most of the work).

The 370s were all m'coded ... with the 115-145 being vertical m'coded
machines (effectively the native processor engines were programmed
much like a 16-bit microprocessor which effectively simulated 370
instructions at about 1/10th the native processor engine speed ... aka
the native processor engine speed in the 370 processors were approx.
ten times faster than the respective 370 MIP ratings ... aka a .1mip
125 needed a 1mip native processor engine).

The 155, 158, 165, 168 were all "horizontal" mcoded machine
... effectively wide instructions that controlled the various
functional units in the hardware ... and there could be multiple
operations specified, started, and going on simultaneously ... with
one m'code instruction executed per machine cycle. Rather than rate
the m'code in terms of m'code instructions per 370 instruction, the
machines were rated in avg. number of machine cycles per 370
instruction (because of the ability to have multiple things going on
simultaneously in the same m'code instruction). For instance, the 165
ran at about 2.1 machine cycles per 370 instruction, optimization for
168 reduced that to about 1.6 machine cycles per 370 instruction.
http://www.garlic.com/~lynn/96.html#23

Except for the high-end 360 & 370, the machines had "integrated" I/O
channels ... i.e. the m'code on the native engine not only implemented
the 370 instruction set ... but also the channel command instruction
set ... and the native processor engine basically was multiprogrammed
between executing 370 instruction set and channel command operations.

The 303x was interesting because it re-introduced a limiting version
of channel director (still lacked the full SMP capability of the 67
controller). A channel director was an external engine that
implemented six I/O channels. A 3033 needed three channel directors
for a 16 channel configuration. The channel director was a 370/158
with the 370 microcode removed and the box dedicated to the channel
I/O microcode.  A 3031 was a 158 processor reconfigured w/o the
channel I/O microcode running only 370 instruction m'code (relying on
a 2nd 158 engine configured as a channel director to implement the I/O
function).  A 3032 was basically a 168 configured to work with 158
channel director engine. A 3033 was basically a 168 remapped to faster
chip technology.  A 3031 was faster than a 158 in large part because
the engine wasn't being shared between 370 and channel functions
(there were two dedicated engines one for each function)
http://www.garlic.com/~lynn/97.html#20
http://www.garlic.com/~lynn/2000d.html#82

The precusor to such an implementation was the 115 & 125. The basic
hardware for the two boxes was the same, a 9-way SMP shared memory
bus. A 115/125 configuration tended to have 4-9 independent processors
installed in a configuration ... but a standard confgiruation only had
one of the processors executed "m'code" for 370 instruction set.  The
other processors implemented "m'code" for other configuration
functions; disk controller, telecommunications controller, etc. In the
115 all the processors were identical ... only differentiated by the
"m'code" program that the processor was executing. In the 125, the
processor engine that execute the 370 m'code was about 25percent
faster than the other engines.
http://www.garlic.com/~lynn/2001i.html#2
http://www.garlic.com/~lynn/2001j.html#18
http://www.garlic.com/~lynn/2001j.html#19

There were numerous special m'code developed for various 360 and 370
engines. A common special m'code on the 360/67 implemented the SLT
(search list) instruction ... which could search a chained list of
elements looking for matching on various conditions. There was a
conversational programming system (CPS) developed by the boston
programming system that had interpreted PL/I and Basic(?) along with a
whole slew of special instruction m'code for 360/50 (CPS could run
either with or w/o the special m'code).

The 370/145 had large m'code load for the vs/apl m'code assist (apl
programs with the m'code assist on 145 ran about as fast as on 168 w/o
m'code assist).

The 370/148 had portions of VS/1 and VM/370 kernel implemented in
m'code as performance assist aka most kernel instructions mapped 1:1
into m'code so there was corresponding 10:1 performance
improvement. Other VM/370 kernel assist were modifications to the way
privilege instructions executed in "VM-mode", this allowed the
instruction to be executed w/o taking an interrupt into the VM/370
kernel, saving state, simulating the instruction, restoring state,
resuming virtual machine operation ... which resulted in significantly
greater than 10:1 performance improvement.
http://www.garlic.com/~lynn/94.html#21

The various control units were also m'code engines. The 3830 disk
controller was a horizontal m'code engine ... but was replaced with a
vertical m'coded engine, j-prime, for the 3880 disk controller.
http://www.garlic.com/~lynn/2000b.html#38
http://www.garlic.com/~lynn/2000c.html#75
http://www.garlic.com/~lynn/2001l.html#63

The 3705 was a uc.5 (vertical m'coded) engine ... which was also used
in a number of other boxes, including the 8100 and as the service
processor in the 3081.
http://www.garlic.com/~lynn/2002.html#45

I'm not sure about the details of various 360 controllers ... but as
an undergraduate, I worked on a project with three others that reverse
engineered the ibm channel interface, built our own channel adapter
board and programmed a minicomputer to be a plug compatible
telecommunication controller (2702 replacement) ... and have been
blaimed for originating the IBM PCM controller business
http://www.garlic.com/~lynn/subtopic.html#360pcm

and possibly also responsible for the baroque nature of the PU4/PU5
interface
http://www.garlic.com/~lynn/2002.html#11

--



Tue, 29 Jun 2004 22:54:22 GMT  
 Microcode?
The 360/25 was microcoded.
In fact, a card deck was loaded for microcode for 1400 or 360
emulation.  I actually patched the 1400 deck and the DOS 360/30 code
for printer channel controls for a bug I found.  (IBM's local sales
traded me a full set of emulator docs for the patch)

Jeff Raben
and stir with a Runcible spoon...



Tue, 29 Jun 2004 23:18:05 GMT  
 Microcode?
Oh yeah! The "CID." Compatibility Initialization Deck. My first job as an
operator, I was issued my very own CID. So proud...



Quote:
> The 360/25 was microcoded.
> In fact, a card deck was loaded for microcode for 1400 or 360
> emulation.  I actually patched the 1400 deck and the DOS 360/30 code
> for printer channel controls for a bug I found.  (IBM's local sales
> traded me a full set of emulator docs for the patch)

> Jeff Raben
> and stir with a Runcible spoon...



Tue, 29 Jun 2004 23:28:47 GMT  
 
 [ 46 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Microcode Assist for VSAPL

2. F21 microcode

3. 68332 TPU microcode assembler?

4. CISC Microcode (was Re: RISC Mainframe)

5. Verilog implementation of microcoded 8-bit CPUs

6. Newbie microcode question

7. Microcode?

8. MicroCode

9. triggering a microcode update

10. Microcode?

11. Saving microcode investment for IDT 49c402 16 bit slice

12. Save your 49c402 microcode investment

 

 
Powered by phpBB® Forum Software