The major d i ffe rence between the software architectures of the MicroVAX and the fu ll VAX systems is the group of instructions that were
Digital Technical journal
not implemented i n the chip hardware . This group consists of
• Floating point i nstructions • Packed decimal instructions
• Character string instructions
(The MicroVAX architecture included the MOVC3 and MOVC5 instructions because they were heavily used in fu ndamental rou t i nes, such as copying or fi lling memory arrays .)
Each of the three operating systems was sup ported by a d i ffe re nt design grou p . These groups had to decide which course of action to take to accommodate the reduced number of instructions that wou l d be implemented in microcode. The fol lowing alternatives were the most realistic courses to tak e :
1 . All compilers and assemblers could be changed to eliminate all uses of the miss ing i nstructions .
2 . Emulation subrouti nes that appl ications could link into their programs could be supplied. (VMS used this method on early VAX models that did not include h a r d w a re s u p p o r t for t h e G a n d H floating point data types.)
3 . The e m u lation subro u t i nes could be implemented so that their use would be invisible to application programs and even to most of the operating system.
The VMS Decisio n Pro cess
The VMS design team began a study to deter mine the extent to which the m issing instruc tions were used in the operating system cod e , including all the various VMS u t i l ity programs. As expected, the character string i nstruct ions were used most frequently and, in fact, were more widely used than expected. The CMPC 3 , CMPC5 , and LOCC instructions were the most frequently used string i nstructions, occurring almost everywhere that ASC I I text was manipu lated ( for exam p l e , in device names , fi le names, and DCL commands) . All software that included some kind of bi tmap (about six to ten different areas, ranging from the file system to memory management) used the SCANC and SPANC instructions. A large nu mber of table lookup designs (including DCL and u til ity com mand parsers) used the MATCHC, MOVTC, and MOVTUC instructions . Finally, the CRC instru c-
Digital Technical journal
No. 2 March 1986
tion was used by the BACKUP utility and by the DECnet code .
Very few data types were used outside their realms and only a few u nexpected sequences were found that used the missing instructions. One example was the use of the CVTLF instruc tion in the VMS kernel to determ ine the small est power of 2 larger than a given integer. A second example was the use of the CVTLP instruction i n the FORTRAN run-time support library as a quick method for converting binary representations to text.
Once the extent of the missing instruction usage was determined, the design team consid ered the number of compilers that were sup ported by the VMS operating system. I n all, over fifteen different languages are supported .3 The first alternative, c hanging t he compi lers and assemblers, would requi re that the code gener ators for each product be changed. Moreover, new versions of the VMS operating system and all its layered products would have to be gener a ted using these new compilers. That would involve a significant i nvestment of manpower, not just to enhance the compilers, but to pro vide ongoing support to maintain each product. In addition, two variants of each new version of each product would have to be produced . A l i kely side effect was that these changes wou l d probably cause other development groups to l imit most layered produ cts to the MicroVAX subset on all VAX machines . I n that way, each group wou ld have to maintain only one version of their product .
Another consideration was the effect that the first or second alternatives wou ld have on the marketing of MicroVAX systems. Customers and Digital's software engineers had become accus tomed to developing software on one machine and executing it transparently on any other machine in the VAX family. That wou ld not have been possible u nder either of the first two alternatives.
Through this reasoning process, it became obvious that the correct choice was the third alternative, to design for software emulation and make it transparent to both applications and operating system code . While requ iring a concentrated effort to write the emulation sup port , the overall effort for software emulation was much smaller than removing the use of the missing instructions from existing software and com piler code generators . The effort was also
isolated. While some new code was needed, the number of changes to existing components was minimized . These changes were confined to the exception handler and the startup routi nes for the operating system . Finally, transparent emu lation of all missing instructions would guaran tee that systems implementing the MicroVAX architecture would be fully compatible with the VAX family of machines.