Information Technology Reference
In-Depth Information
preservation using emulation as a preservation strategy. In this case, the relative
execution speed (instruction timing and duration problems as mentioned previously)
need only be considered when considering the feel, as it is assumed that the emula-
tor will run the software at the original speed in the future when hardware systems
are faster.
When preserving emulation software though, we must also consider that it will
be more than likely preserved as source code. Preserving the binary form of an
emulator would then mean that it itself would have to be run on an emulator in
the future. This could potentially cause problems as the speed of execution of the
software being preserved would be slowed by a factor of the product of the speed
reduction of the two emulators. So if both emulators ran software 500 times slower,
then the software being preserved would run 25,000 times slower than it did on the
original hardware. Given that the speed of hardware roughly doubles every 2 years
this would mean the software would only run at its original speed on hardware 28-30
years in the future. Carrying on running emulators in emulators means that the time
before the software runs at the original speed can increase dramatically. Preserving
the binary form of the emulator is therefore probably not a really practical solution,
although in principle it serves its purpose.
Preserving the source of the emulator for the long-term also has its problems. In
the first instance the source code would have to be recompiled for the new hardware
system. Any software source code being transferred to a new system usually invokes
software porting problems. Porting software usually means it has to be modified
before it will compile and run correctly; this takes time and effort. Even if one
ports the software and gets it to compile, one is still left with the same problem as
discussed above when software is re-implemented, namely that that the software has
to be tested and compared to the original to ensure that it is behaving and running
correctly. To do this, the tests, test data and the corresponding test outputs from the
original emulator also have to be preserved along with the emulator itself.
Another potential problem also arises in the very long-term when preserving
source code for the emulator. The source code will be written in one or more pro-
gramming languages which will need complier software to produce machine code
so that it can be run. In the future there is no guarantee that the required compil-
ers will exist on any future computer systems, which could potentially render the
emulator code useless. The source code for the emulator may still be of some use
though, but only as “documentation” that may guide someone willing to attempt to
re-implement the emulator in a new programming language. It would be much better
in this case to have sufficient documentation about the old hardware so as to capture
enough information as to make the reimplementation possible. Such documentation
would include information about the CPUs instruction set [ 86 ], and information
about the peripheral hardware functionality and supported instructions.
One question remains about instruction emulators, and that is, why is it not better
to just preserve the source code for the software that needs to be preserved and
then port it to future systems? The main argument for this is that an emulator will
allow many different applications to be run, and thus the effort in porting or re-
implementing an emulator is far less that that required to port or to re-implement a
Search WWH ::




Custom Search