virtual memory 4488

old post discussing how hardware address translation worked on trout 1.5 (3090), including email from fall of '83

there is a reference to Birnbaum starting in early '75 on 801 project (including split caches), i.e. 801 turned into romp, rios, power, power-pc, etc. misc. past posts mentioning 801

and old discussion about SIE (virtual machine buttist) from long ago and far away (couple weeks short of 25years ago):

I would like to add a bit more to the discussion of SIE. I seem to have hit a sensitive area with my original comments. I would have preferred to contain this to an offline discussion, but I feel that some of the things that have appeared in the memos require a reply.

First, let me say that all of the comments I have made have been accurate to the best of my knowledge. The performance data I quoted came directly from a presentation I attended given by the VM-811 group. The purpose of the presentation was to justify extensions to the SIE architecture. Since I my last writing, I have been told by loveXX that the numbers quoted were for MVS running under VMTOOL on the 3081. lovelove mentioned that VMTOOL has some significant software problems which are partially responsible for the poor performance. Presumably, VM-811 would not have these problems. This was not pointed out at the meeting.

For many years the software and hardware groups have misunderstood each other. Engineers who knew nothing about software could not understand why it was necessary to make their hardware do certain things. Likewise, programmers who knew nothing about software could not understand why the engineers could not make the hardware do the things they wanted. Traditionally, microcode has been done by engineers because a thorough understanding of the hardware is necessary in order to write microcode. In recent years, this has become a problem as more complex software functions have been placed into microcode. In my department, we have tried to remedy this problem by hiring people with programming experience as microprogrammers.

The statement that millions of dollars have been spent writing microcode in order to avoid putting a few ten cent latches into the hardware is completely false. The truth is that changes have often been made to the microcode to AVOID SPENDING MILLIONS OF DOLLARS by putting a change in hardware. In the world of LSI and VLSI, there is no longer such a thing as a "ten cent latch." Once a chip has been designed, it is very expensive to make even the smallest change to it.

Microcode offers a high degree of flexibility in an environment that is subject to change, especially if one has a writable control store. When a change is necessary, it can often be had for "free" by making a change to the microcode and sending out a new floppy disk, whereas it might cost millions of dollars to make an equivalent change to the hardware. While the performance of the microcode may not be as good as the hardware implementation, the overall cost-performance has dictated that it is the method of choice.

As I pointed out in a previous writing, what works well or does not work well on one machine says absolutely nothing about the performance of that item on another machine. loveXX seems to have completely missed this critical point, since he expects a 158-like performance boost from SIE on machines which are nothing like the 158 in their design.

SIE is a poor performer on the 3081 for several reasons. One reason is that the 3081 pages its microcode. Each time it is necessary to enter or exit SIE, a large piece of microcode must be paged in to carry out this function. This is rather costly in terms of performance. A performance gain could be realized if the number of exit-entry trips could be reduced. One way of doing this would be to emulate more instructions on the buttumption that it takes less to emulate them than it does to exit and re-enter emulation mode. This thinking is completely valid for the 3081, but is not necessarily relevent when it comes to other machines, such as TROUT.

TROUT does not page its microcode, and therefore the cost of exiting and re-entering emulation mode is less. The thinking behind the changes to the SIE architecture should be re-examined when it comes to TROUT because the data upon which the changes were based is not necessarily valid. This is why I have asked that the extensions to SIE be made optional. This would allow machines that do have performance problems to implement the extensions, while machines that do not have problems could leave them out and use their control store for more valuable functions.

The extensions that are being proposed are not at all trivial. It may seem like a simple matter to emulate an I-O instruction, but such is not the case. To appreciate what is involved, one must have a detailed understanding of just how the CPU, SCE and and Channels work.

Other machines do indeed have an easier time when it comes to implementing some of these buttists. That is because they are rather simple machines internally, not because their designers had more foresight when they designed the machines. The cycle time of TROUT is only slightly faster than the 3081, yet TROUT is much faster in terms of MIPS. This performance comes from the highly overlapped design of the processor. This makes for a much more complex design. Sometimes you pay dearly for this, like when it comes to putting in complex microcode functions.

TROUT has never treated SIE as "just another buttist." SIE has been a basic part of our machine's design since the beginning. In fact, we have chosen to put many functions into hardware instead of microcode to pick up significant performance gains. For example, the 3081 takes a significant amount of time to do certain types of guest-to-host address translation because it does them in microcode, while TROUT does them completely in hardware.

... snip ...

nomenclature in the above with "guest" refers to an operating system running in a virtual machine.

...

with regard to the above comment about virtual machines and I-O instruction ... part of the issue is translating the I-O channel program and fixing the related virtual pages in real memory .. since the real channels run using real addresses from the channel programs. the channel programs from the virtual address space have all been created using the addresses of the virtual address space. this wasn't just an issue for virtual machine emulation ... but OS-VS2 also has the issue with channel programs created by applications running in virtual address space.

...

3090 responded to Amdahl's hypervisor support with PR-SM, misc. past posts mentioning PR-SM (and LPARs)

...

misc. past posts mentioning CCWTRANS (cp-67 routine that created "shadow" channel program copies of what was in the virtual address space, replacing all virtual addresses with "real" addresses, for example initial prototype of OS-VS2 was built by crafting hardware translation into mvt and hacking a copy of CP67's CCWTRANS into mvt):

--