The system is designed to handle from 50 to 1,000 or more units to both emergency and non-emergency situations using radio data links. If Unix machines are to make serious inroads into the office automation/personal computer market, they will have to run MS-DOS programs efficiently. Until now, a Unix user who wanted to run MS-DOS applications on a machine with a non-Intel processor had two choices, neither of them very attractive: use software to emulate the MS-DOS application in the workstation or multi-user computer’s Unix environment and watch it slow down to a frustrating snail’s pace: or spend around $2,500 for each workstation on an add-in card containing an Intel 8086 or 80286 processor to run the application. Now Hunter Systems Inc of Mountain View, California, has come up with a third alternative, called XDOS (CI No 923). Unlike an emulator, which runs alongside an application each time it is run, translating it line by line into machine code for the target machine, XDOS uses techniques from the new smart optimising compilers to translate the MS-DOS program’s binary code into binary code that can run under Unix. This one-time operation converts the application into a Unix program that will run on the target machine as fast or faster than the original MS-DOS program would on a personal computer. Global-flow analysis A front-end software processor in XDOS performs a global-flow analysis – a technique to discover and describe the logical structure of a program – on the MS-DOS application and determines how it uses the operating system and hardware before converting the program into a Unix application. This is then passed to a machine-specific back-end (currently for the Motorola 68020, with the Intergraph Clipper and another RISC version in the pipeline) which executes the program in the Unix environment. Hunter Systems president Colin Hunter refused to comment on suggestions that he was producing a Sparc-Computer Consoles Inc RISC translator. However he said that translating from RISC architectures could be somewhat simpler than translation from complex instruction architectures. Translating to RISC has some technical advantages, but they are usually cancelled out by the added problems caused by other architectural features. A conventional emulation runs alongside the application, generating 68020 instructions for every MS-DOS instruction. Because it can only evaluate the application one line at a time, in real-time, it has to generate a lot of unnecessary 68020 instructions – as many as 15 target instructions for every instruction in the original MS-DOS application. For example, the global-flow analysis can intelligently evaluate whether to evaluate the condition codes and flags that are set after some instructions. An emulator that evaluates code line by line has to translate them all just in case they are needed later, whereas by working through the logic of the whole program, XDOS can determine which will be referred to later in the program and which are not referred to again and can be ignored. An arithmetic or logical operation can produce a number of results overflow, a zero result, a negative or a positive result. Each of these conditions sets a flag which the application can refer to later in the program after the instruction has been executed. Most of the time however, the flags are not relevant to the program and will never be examined. When an applications programmer writes an add instruction he or she may never examine the flags after the operation – if the result does not affect the flow of the program, there is no need to look at the flags. Global-flow analysis looks ahead in the program to determine which flags, if any, are checked after each operation. If none are checked, none are simulated in the target code; if one or more are checked (or may be checked, depending on the outcome of a branch condition) only those that are relevant are simulated. An emulator, however, has no way of knowing which may be checked later in the program, so it has to assume the worst and simulate all the condition co
des and flags after each operation. As an application may contain a large number of these operations so the emulator will soon run out of registers to hold the flags. It must then create and protect a large area in the memory to hold all the flags and condition codes, the vast majority of which will never be needed. Another example of how the global-flow analysis makes the XDOS code more efficient is in the determination of when to compensate for differences in the machine level programming conventions on the 80286 and the 68020. On the 80286, a move instruction does not change the flags when it is executed. But on the 68020, a move instruction sets all flags to zero. A program emulating the 286 on the 68020 will have to save all the flags because it will have no way of knowing whether one or more of them will be tested by a later instruction. System calls After the front-end processor has converted the code into binary code for the 68020 it still will not run, as it has no idea what hardware is used in the system and how to address it, and it still makes system calls to MS-DOS, the IBM BIOS and the Personal Computer hardware. The back-end processor takes care of these tasks. Each hardware system implementing XDOS must have its own back-end to direct the system calls to their Unix equivalent in a special library. According to Colin Hunter the library contains functions that emulate the three elements of the operating system with which the MS-DOS applications usually interacts during execution. When the application opens or closes a disk file, accesses the BIOS, or writes a bit pattern to the control register of a device, the back-end processor knows what the application is attempting to perform because of the previous global analysis, Hunter says. It accesses the library function that provides the Unix resource to perform the function most efficiently. Mostly what the back-end processor does is redirect the MS-DOS call down to the appropriate Unix resource. As a result, the overhead associated with XDOS is small. Instead of simulating the whole behaviour of the device, we’re just mapping it down into Unix. Running the MS-DOS code through the front-end is a one-off operation that takes around five to 10 minutes, but it produces a Unix application that can be used any number of times and be shared by all the users on the system. The first front-end produces 68020 code, but work is under way to do back-ends for the Clipper and another RISC. XDOS is being licensed to OEM customers at $425 to $2,000 depending on size of the system.
Content from our partners
