Hi,

In VM anyway we never used the linkage stack with program tranfer or return.
BAS and BASR were important because a lot of code had to be cleaned because
of use of the extra byte you get with the BAL, BALR and LA. I don't recall
if LRA had a problem but don't see how it could.  I haven't looked at things
recently. Where is the STO saved in VM? I've heard on the 64 bit machines
there is so much RAM that separate cache's of some types have been done away
with though they exist as part of the design of the operating system and
maintain the same name.

I guess cycle time fasciantes me because I picture a bunch of processors on
the same bus being fed part of instructions in synch with the cycle and
clock and the address translation taking place in rhythm with the cycles.
Probably doesn't work the way I imagine it.

I remember one line item called share capping that was supposed to improve
how the dispatcher divided up resources between users more fairly.

HCPRUN always bothered me. 

Paul 

-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Phil
Payne
Sent: Saturday, December 13, 2003 7:26 AM
To: [EMAIL PROTECTED]
Subject: Re: Technical Specs


> Multi level cache, translation lookaside buffers and a number of other
> items
come to mind.

Segment Table Origin Register Save Stacks.  Each TLB entry is "tagged" with
the STO it corresponds to.  If an address space switch occurs, a new STO is
loaded but the old one is saved in a stack and its TLB entries are tagged.
If the old one is ever restored, the corresponding TLB entries are
immediately returned to validity.  Came in with the 3033, I believe.

And other stuff.  Loads of it.  Cycle time isn't even a valid comparative
metric between different generations of IBM processors, except that it shows
what technology level they're using.  And I'm not sure that is very
interesting.

Different CPU designers used different degrees of this stuff at different
levels.  In the 1980s, it seemed that IBM's designers were aiming at a sweet
spot around 70% CPU - Amdahl's aimed at 95%.  The relative performance of
these systems changed with CPU load - the Amdahl machine got "faster" the
more it was loaded.

--
  Phil Payne
  http://www.isham-research.com
  +44 7785 302 803

Reply via email to