-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Dean Kent
Sent: Friday, July 20, 2007 4:18 PM
To: [email protected]
Subject: Re: PSI MIPS (was: Links to decent 'why the mainframe thrives'
article)
<snip>
Frankly, I think it is a very commonly held belief amongst many who are
very
knowledgable about processors. In fact, my original comment that they
are
slower was based largely upon discussions to this effect on various fora
where CPU architecture is a common topic - often by those who are
involved
with chip design. I would be *very* happy to be able to report to these
individuals that I have contradictory information... in the form of
factual
data, rather than just dismissive comments, of course. :-).
Regards,
Dean
<SNIP>
I am amazed that those who know processors would be that ignorant of
data bus size on effective speeds or microcode word sizes, etc.
Think about this for a moment. If your data bus is 32 bits wide, a move
instruction (assuming boundary alignments here) can only move 4 bytes
per unit of operation. Now, the G6 (was it?) went to 256 BYTES wide. How
long to move data from one record to another, assuming 4K records,
between those two situations (as in number of cycles)?
Next we have arithmetic. Ok, up until recently the registers were the
same size, and so fixed binary arithmetic is done faster on a system
with a faster clock. But the majority of IBM mainframe arithmetic is
done with PACKED DECIMAL (that Decimal Feature from S/360 days). While a
bit slower than Fixed Point, it is much faster than Floating Point.
As a result of the Decimal Feature, edit of numbers for placement on a
report is done in microcode on IBM's mainframe platforms. I do not know
of a similar instruction for the x86 chips (but then, I'm not an x86 ALC
programmer). [Any body want to write a C++ class (?) to emulate this?]
Memory access is yet another thing. Mainframes, in order to access > 2GB
of memory had to have expanded registers under the covers (ever since
you could have more than 2GB on a machine). Virtual storage (DAT) has
been fine tuned on mainframes for years. Then there are the cache line
sizes and life in cache, etc. All of this plays to the ability to do
LPARS and now 64bit addressing. Microcode and/or circuitry issues.
Next, with DAT, are the algorithms for MP communication (E.g. for
mainframe: SIGP, CD, CSD, PLO, PLT, IPTE, SSKE, etc.), etc., that all
have to be there for CPU and CEC communication so that integrity of
data/operations are maintained. All of this involve both circuitry and
microcode -- or the SCP must provide routines to do it.
A dual core CPUs actually cause themselves a bottleneck if they only
have ONE bus to communicate to/with the outside world. This becomes
another design issue that while producing apparent processor speed has
to balance out against the ability of the bus (or buses) to handle data
flow (which gives effective processor speed).
Multi-CPU (multiple CPU chips) communications require motherboards and
other chips to help solve simultaneous update issues (corrupted data)
because of race conditions. These are more circuitry and/or microcode
issues.
The other thing that is not looked at (and I do not know the answer for
IBM's chips), is the apparent speed of the clock vs. the microcode clock
speed. There are machine designs where the microcode is running 2-8
times the speed of the system clock, so that you have an apparent speed.
These things are also part of the RISC vs. CISC designs and arguments.
Obviously the IBM mainframes have been Complicated Instruction Set based
systems for a very long time (in the grand scheme of things).
And it has been years since I worked at Amdahl where some of this was
discussed from time to time. So I'm starting to forget issues.
Regards,
Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
