Because the decimal/string emulator relies on hardware for its operand decode stage , the lookahead technique used by the floating point emu lator cannot be used for decimal and string instructions . I f the i nstruction fol l owing an emulated instruction also requ ires emulation support, the following sequence takes place :
1 . The first exception is dismissed. 2 . The next instruction is execu ted.
3 . The operands of t hat i nstruction are decoded and stored on the stac k.
4 . The d e c i m al/string e m ulatOr regains contro l .
Since these instructions perform many unre lated operations, t here is little code that can be shared between their emulation rou tines.
Testing and Debugging
The main problem i n testing the emu lation s o ftware i n i t ia l ly was t h a t t h e re was no MicroVAX hardware available du ring most of the implementation cyc l e . Thus we had to deve lop techniques to simu late the hardware in order to begin the tests . There were two chief techniques used to test and debug the emula tor. First, instru ction-specific routines were tested as user-mode programs in a normal pro gram development environ ment . Secon d , the exception handler front-end was tested on a VAX - 1 1 /7 3 0 system that was m od ifie d , by rewriting some of the 1 1 /7 3 0 mi crocode, to act l i ke a MicroVAX system .
Instructio n-Specific Testing
Microcode written for a particular implementa tion (both VAX and MicroVAX systems) can be used only on that particu lar machine or a simu lation of that machine . However, macro-level code can be executed on any VAX processor. Therefore , since the emu lation routines were written in macro-level code that executes on any VAX p rocessor , " no r m a l " d e b ugging
Digital Tecl:mical journal
techniques could be used for part of the debug effort .
A set of test programs was constructed that would run on other VAX processors ( 1 1 /7 3 0 , 1 1 /7 5 0 , a n d 1 1 /7 8 0 ) . These test programs would call each instruction-specific subroutine and compare the resu lts (memory contents, reg ister contents, and settings of the condition codes) with the output from the corresponding instru c tions executed on those processors . These tests allowed the basic a lgorithms to be debugged even before they were plugged i nto the emulator. The set of tests was limited only by the choice of input data for each instruction.
The first set o f tests u nc overed m o s t algorithmic problems b u t d i d not exercise the error paths (such as inaccessible source or des tination strings) . The code to handle these error conditions was written later in the develop ment cycle . Neither the absence of these error paths nor errors in edge conditions (such as zero-length strings) prevented the VMS system from executing.
Another benefit of a macrocode implementa tion was seen during the debug of the edge condition problems. Since the instruction emu lation routines were just an extension of the operating system, the debugging tools used for other operating system code cou ld be used to debug the emulator.
Testing the VAX- 1 1/73 0 Breadboard Implementation
The availab i l i ty of the two new emu lation exceptions changed the strategy for debugging the emulation code . The software solution used to obtain preliminary resu lts was u nable to mimic the new exceptions invented to assist the emulatio n . Therefore, a new testbed was needed to accommodate the debugging pro cess . The testbed had to decode the operands and generate the appropriate exceptions to pass control to the software emulation code . One way to perform these functions was to alter an existing VAX system, such as the VAX- 1 1 /7 3 0 processor.
The 1 1 /730 is an entirely " soft" machine; that is, all its microcode is loaded at powerup rather than being resident in ROM. By altering that microcode, the design team could make the 1 1 / 7 3 0 look l ike the architecture in a M icroVAX system . The required changes were simply a matter of removing the microcode for
Digital Technical journal No. 2 March 1 986
instruction execution while leaving that for operand decode . To finish the alterations, the design team had to write a new "exception gen erator" to create the emulation exceptions.
At this time in the project, the first real MicroVAX hardware wou ld still not be available for nine months. Therefore , the VMS design team decided to undertake the modifications to the 1 1 /7 3 0 's m icrocode and to b u i l d t he testbed. We estimated that this effort would take one to two months, since the VMS devel oper had to learn to write microcode . That meant that the software emulation code would s t i l l be c o m p l et e d l on g before t h e first MicroVAX hardware was ready.
The m i crocode s o u rc e programs w e re acquired from the 1 1 /730 m icrocode team and assembled u s i n g the l a test vers i o n of the microcode assembler. The 1 1 /7 3 0 microcode was structured as separate modu les for different functions (for example , floating point, compat ibility mode, exceptions, memory management, and so on) . Due to the lack of a " linker," label files that allowed routines to be called across modules had to be created. To speed the devel opment, the design team wrote several FOR TRAN tools that automatical ly generated new
label files . In addition , command files were built that correctly created a new set of binary microcode files from a set of modified sources .
The next step was to change the 1 1 j730's microcode . Since it had to exist in a limited amount of RAM space, the new code could not be added without removing some existing code . Therefore , we decided to replace the compatibi lity mode microcode with a new rou tine to generate the emulation exception. Some new flags were added that, at the developer's c h o ice , w o u l d a l low d i fferen t c l asses of instructions to be e m u lated ( i . e . , decimal string, c haracter string, or floating point) . F i n a l ly, to boot the VMS syst e m o n t h is MicroVAX version of an 1 1 /730 , we had to enhance the VMS bootstrap code to load the emu lation exception hand lers and connect them to the appropriate exception vectors.
Now the software emulation code , from the exception handler all the way down to instruc tion execution, could be debugged . The best measure of the success of this venture was made when M icroVAX hardware was finally available. The customized VAX - 1 1 /7 3 0 system was such a good testbed , not o n ly for the
instruction emulator but also the rest of the MicroVAX I support, that it took a mere four days to get the VMS system running.