MicroVAX - A Subset VAX Architecture ------------------------------------ MicroVAX - A Subset VAX Architecture ------------------------------------ WHY define a subset VAX architecture WHAT is the subset HOW will VMS support the MicroVAX architecture MicroVAX - A Subset VAX Architecture ------------------------------------ WHY define a subset VAX architecture o What are the implications of a subset architecture o Why is a subset architecture necessary WHAT is the MicroVAX subset HOW will VMS support the MicroVAX architecture The Implications of a Subset ---------------------------- The operating system serves as an interface between base hardware and user applications. +---------------------------------------------------------------------+ ! Nonprivileged programs ! +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ ! ! ! Operating System ! ! ! +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ ! ! ! ! ! ! ! Base Machine ! +---------------------------------------------------------------------+ It is the combination of the base hardware and the intervening operating system that comprise the environment, the so-called virtual machine, in which user programs operate. The Implications of a Subset ---------------------------- As far as application programs are concerned, a processor conforming to the subset architecture is simply another VAX family member. o Base hardware conforming to subset architecture contains less functionality. o Operating system assumes responsibility for implementing the missing functionality. o The virtual machine that the user sees has not changed. The Implications of a Subset ---------------------------- Operations formerly performed in microcode have migrated to software. +---------------------------------------------------------------------+ ! Nonprivileged programs ! +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ ! ! ! Operating System ! ! ! +- - - - - - - - - - - - - - - - - - + ! ! ! Instruction Emulator ! ! + - - - - - - - - - - - - - - - -+ ! ! ! Base Machine ! +---------------------------------------------------------------------+ This means that all user applications will run without modification on machines that conform to the subset architecture. Why Is a Subset Necessary ------------------------- o Microcode size is fairly large. o Microcode size depends mainly on the architecture and is largely unaffected by the underlying implementation. Small number of wide words (7K x 80 on 11/750) Larger number of narrow words (16K x 24 on 11/730) o Full architecture requires multi-chip VLSI implementation. o Reasonable subset can be implemented as a single chip microprocessor. MicroVAX - A Subset VAX Architecture ------------------------------------ WHY define a subset VAX architecture WHAT is the MicroVAX subset o The full VAX architecture o Implementation details not described by the architecture o How decisions were made on what to include in the subset o What was excluded from subset o What was included in subset HOW will VMS support the MicroVAX architecture What Is the Full VAX Architecture --------------------------------- The architecture describes the machine interface visible to the programmer. o Data Types o Addressing Modes o Instruction Set o Memory Management o Exceptions and Interrupts o Process Structure o Processor Registers o Compatibility Mode What Is the Full VAX Architecture --------------------------------- Classification of Instructions (or Data Types) o Integer and Logical o Branch and Other Control (including CALLx and RET) o Miscellaneous Instructions (including address manipulation and queue instructions) o Variable Length Bit Field o Floating Point F_floating D_floating G_floating H_floating o Character String (including CRC) o Packed Decimal (and decimal string) o EDITPC o Privileged Instructions What is NOT a Part of the VAX Architecture ------------------------------------------ Implementation details invisible to all except select pieces of the operating system o Memory and I/O bus structure o Size of physical memory o Presence and details of Instruction Buffer Instruction Accelerator Physical Memory Cache Translation Buffer o Console Implementation o Processor-Specific Privileged Registers o Machine Check (processor-specific errors) Criteria for Subset Definition ------------------------------ What formed the basis for subset definition o Achieve largest savings in microcode size (by moving the most complicated instructions to software) o Affect the smallest class of programs (in terms of performance) o Have little or no impact on the operating system internals, especially drivers and other time-critical code o Subset should be architecturally reasonable and easy to describe What Was Removed from the Subset -------------------------------- What instruction classes were not included in the subset o Compatibility Mode o EDITPC o D_ and H_floating (and MOVO and CLRO) o Decimal string (including all packed decimal and numeric string instructions) o Character string and CRC (except MOVC3 and MOVC5) o F_ and G_floating were made optional Other Differences ----------------- o Hardware ignores DV bit in the PSW. o There may be a null TBCHK register. o A MTPR to TBIS may invalidate more than a single entry in the translation buffer. For example, TBIS may be equivalent to TBIA. o Several architectural requirements were relaxed No console interface defined by the MicroVAX architecture No interval timer No Time-of-Year clock o The clocks and console are most likely implemented but no longer required nor subject to architectural constraints. Rejected Ideas -------------- o Subset memory management o Remove ACBx, EMODx, and POLYx (for F_ and G_floating) o Remove INDEX o Remove other infrequently used instructions What Was Included in the Subset -------------------------------- Everything that was not mentioned as being removed from the subset is included. o All addressing modes including all forms of context indexing. o The kernel instruction set Integer and Logical Branch and Other Control (including CALLx and RET) Miscellaneous Instructions (including address manipulation, queue instructions, and INDEX) Variable Length Bit Field MOVC3 and MOVC5 Privileged Instructions o Full VAX memory management o F_ and G_floating are optional members of the subset (including ACBF, EMODF, POLYF, and their G_floating counterparts) MicroVAX - A Subset VAX Architecture ------------------------------------ WHY define a subset VAX architecture WHAT is the subset HOW will VMS support the MicroVAX architecture o Support for a new VAX implementation o Goals of instruction emulation o Description of instruction emulators VMS Support for the MicroVAX Architecture ----------------------------------------- Support for a new VAX implementation o Support new I/O subsystem, machine checks, new peripheral devices, and so on. o We have already done this before (SYSLOAxxx.EXE). o The situation with the console and clocks merely makes the problem more complicated. VMS Support for the MicroVAX Architecture ----------------------------------------- Emulate the missing instructions in software o Two separate images support emulation Floating point emulation Decimal/String emulation o Images are loaded by bootstrap code whenever they are needed and connected directly into the System Control Block (SCB). Goals of Instruction Emulation ------------------------------ Correctness o Emulated instructions must conform to the full VAX architecture. o Emulators are subject to the same architectural verification as a new processor. o Floating point instructions must give the same answer as other VAX family members. Goals of Instruction Emulation (cont.) -------------------------------------- Transparency / Ease of Use o There is no need for programs to explicitly declare condition handlers that will emulate the missing instructions. This is a marked contrast to the current situation with G_ and H_floating emulation. o Users can hardly tell that they are running with an emulator. o Page faults are completely hidden from the user. o Other exceptions such as arithmetic faults and access violations that are detected by the emulator are reflected back to the user. Goals of Instruction Emulation (cont.) -------------------------------------- Speed of Instruction Emulation o Make the emulated instructions as fast as possible. o The decimal/string emulator receives some hardware assist. o The code is loaded into nonpaged or pageable system address space. Goals of Instruction Emulation (cont.) -------------------------------------- Size of Emulator Images o Keep the images as small as possible. o Modest amounts of memory can be used to improve performance (sacrifice space for speed). o The decimal/string emulator uses several 256-byte tables for fast conversions. Description of Instruction Emulation ------------------------------------ Floating Point Emulator (Description) o The LIB$EMULATE procedure that existed in Version 3 was modified. This was a condition handler that emulated G_ and H_floating instructions. Support was added for F_ and D_floating (with practically no increase in image size). The condition handler was converted into a loadable image. o This image is always loaded on a MicroVAX (because D_ and H_floating are never there). Description of Instruction Emulation ------------------------------------ Floating Point Emulator (Description) o The image is also loaded on a full VAX that lacks G_ and H_floating support (such as a VAX-11/780 that does not have the KE780 option). o The procedure called LIB$EMULATE now unconditionally resignals all exceptions. No need for programs to explicitly declare this procedure as a condition handler. Old programs that established this as a handler will continue to work without modification. Description of Instruction Emulation ------------------------------------ Floating Point Emulator (Operation) o All OPCDEC exceptions first go through this routine. o If the opcode indicates a floating point instruction, then access mode is changed to the access mode in which the instruction occurred. o Accessibility of the opcode and each operand is determined with a PROBEx instruction. If an operand is not accessible, an access violation is generated after backing the instruction up to its original state. Description of Instruction Emulation ------------------------------------ Floating Point Emulator (Operation) o Most of the floating point emulator consists of routines that are shared among several instructions. These routines are used to perform the following steps. Each operand is decoded and fetched. Floating point input operands are unpacked into exponent and mantissa. The actual operation (arithmetic, conversion, and so on) is performed. If the result is a floating point number, the exponent and mantissa are packed. The result, if any, is stored. Description of Instruction Emulation ------------------------------------ Decimal/String Emulator (Hardware assist in decoding operand specifiers) o Two new exceptions are defined. They are generated in the mode of the caller. o When an unimplemented opcode is detected, the operands are parsed and placed on the stack along with other instruction state. o If the first-part-done bit is set, no parsing is done. The "old" PC and PSL are put on the stack. Description of Instruction Emulation ------------------------------------ Decimal/String Emulator (Operation) o Control passes through the SCB vector directly to the decimal/string emulator. o A separate routine exists for each emulated instruction with little code sharing along success paths (except in the obvious cases). o The operands are moved from the stack into the appropriate registers for the architecturally defined final state. o The operation is performed with results (if any) being stored continuously. o If an exception (such as an access violation) occurs while the emulator is executing, the intermediate state is packed into registers, the FPD bit is set in the PSL, and the exception is reflected. Exceptions to Assist Instruction Emulation ------------------------------------------ When an unimplemented opcode is detected, the operands are parsed and placed on the stack along with other instruction state. +-------------------------+ ! opcode ! +-------------------------+ ! PC of instruction ! +-------------------------+ ! decoded first operand ! +-- --+ ! ! +-- --+ ! other ! ~ ~ decoded ~ ~ ! operands ! +-- --+ ! ! +-------------------------+ ! updated PC ! +-------------------------+ ! PSL of exception ! +-------------------------+ Exceptions to Assist Instruction Emulation ------------------------------------------ If the first-part-done bit is set, no parsing is done. The "old" PC and PSL are put on the stack. +-------------------------+ ! PC of instruction ! +-------------------------+ ! PSL of exception ! +-------------------------+ The rest of the instruction state, previously stored in registers when an exception occurred, is unpacked and the emulator resumes where it left off. Miscellaneous VMS Support ------------------------- Most pieces of code, including kernel mode code, are being left alone. o VMS will continue its use of character and decimal instructions, even in time-critical places such as the terminal driver. o Compilers will continue to generate character and decimal instructions. o The use of a bootstrap emulator (which emulates LOCC, CMPC3, and CMPC5) permits the use of these instructions, even in the earliest stages of system initialization. Miscellaneous VMS Support ------------------------- A small number of coding changes are being made. o The frivolous uses of unimplemented or optional instructions (such as a CVTLF instruction in the SWAPPER) are being eliminated. o Some of the routines in the math library are being rewritten to eliminate the use of D_ and H_floating instructions. Additional Notes ---------------- The following items are going to be mentioned but they seem too detailed to include on the slides. o There are several items that are defined by the VAX architecture that are not included in either of the lists. Access modes PSW and PSL format Layout of a call frame o G_floating was chosen over D_floating as the preferred double precision floating format. o The way that VMS handles emulator images is a benefit for all VAX systems, not only MicroVAX systems. We will now have a uniform full VAX architecture including G_floating and H_floating on all VAX family members. It is no longer necessary to include LIB$EMULATE in programs that want to use either of these two data types (but existing programs that did include LIB$EMULATE will not be affected by the presence of the emulator). o The routines in the math library that were rewritten were those routines where D_floating (or H_floating) was used to achieve greater accuracy for F_floating (or G_floating). THIS IS NOT A SLIDE