Brian Inglis <[EMAIL PROTECTED]> writes: > In virtual machine environments, software versions of hardware > approaches tends to be used instead of "creating beautiful new > impediments to understanding" (Henry Spencer -- from #8 in "The Ten > Commandments for C Programmers").
old post discussing how hardware address translation worked on trout 1.5 (3090), including email from fall of '83 http://www.garlic.com/~lynn/2003j.html#42 Flash 10208 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 http://www.garlic.com/~lynn/subtopic.html#801 and old discussion about SIE (virtual machine assist) from long ago and far away (couple weeks short of 25years ago): From: zzzzz Date: 6/30/81 15:33:04 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 XXXXX that the numbers quoted were for MVS running under VMTOOL on the 3081. XXXXXX 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. XXXXX 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 assumption 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 assists. 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 assist." 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) http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe? http://www.garlic.com/~lynn/2002o.html#15 Home mainframes http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM http://www.garlic.com/~lynn/2002p.html#44 Linux paging http://www.garlic.com/~lynn/2002p.html#46 Linux paging http://www.garlic.com/~lynn/2002p.html#48 Linux paging http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea http://www.garlic.com/~lynn/2003n.html#13 CPUs with microcode ? http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security http://www.garlic.com/~lynn/2004c.html#5 PSW Sampling http://www.garlic.com/~lynn/2004m.html#41 EAL5 http://www.garlic.com/~lynn/2004m.html#49 EAL5 http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware? http://www.garlic.com/~lynn/2004o.html#13 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004p.html#37 IBM 3614 and 3624 ATM's http://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question http://www.garlic.com/~lynn/2005.html#6 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support http://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode" http://www.garlic.com/~lynn/2005d.html#74 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new? http://www.garlic.com/~lynn/2005h.html#19 Blowing My Own Horn http://www.garlic.com/~lynn/2005k.html#43 Determining processor status without IPIs http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor http://www.garlic.com/~lynn/2006e.html#15 About TLB in lower-level caches http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor ... 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): http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love? http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...] http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline? http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline? http://www.garlic.com/~lynn/2001l.html#36 History http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?) http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post) http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems http://www.garlic.com/~lynn/2002n.html#62 PLX http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's http://www.garlic.com/~lynn/2004m.html#16 computer industry scenairo before the invention of the PC? http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect http://www.garlic.com/~lynn/2004n.html#54 CKD Disks? http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey http://www.garlic.com/~lynn/2005b.html#50 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line http://www.garlic.com/~lynn/2005p.html#18 address space http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory? http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT http://www.garlic.com/~lynn/2006i.html#33 virtual memory http://www.garlic.com/~lynn/2006j.html#5 virtual memory -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
