Heidi writes:
> My understanding of OCTCOMP is that it is supposed to recompile
> compatibility mode program code (for which the source code is not
> available), and make it Native mode.

CM programs are normally executed by an emulator which has to fetch and
decode each CM instruction in the program, then branch to a subroutine to
manually execute the effects of the CM instruction by moving things around
in hardware (i.e. NM) registers.

The CM emulator enforces all the limits on CM code that the "Classic" 3000
hardware did, and so your CM code won't directly see the expanded hardware
capabilities of PA-RISC.

What OCTCOMP does is to pre-translate the CM code into approximately the
same sequence of NM instructions that would be executed by the CM emulator
to run the original CM instructions.  By looking at the code ahead of time,
the overhead of fetching and decoding each instruction is eliminated and the
instructions that would then be invoked by the emulator can be emitted
"inline", so that you end up with a big stream of NM instructions that
perform precisely the same function as the CM emulator would, but faster
because fewer total instructions are required.

There are certain cases where OCTCOMP cannot translate some CM idiom
completely into NM, and so the translated code needs to be able to reference
the original CM instructions for those sequences that could not be
translated.  Thus the result of an OCTCOMP is not a standalone piece of NM
code, but consists of NM code that has dependencies on both the CM emulator
and the original CM instruction stream.

Thus an OCTed program consists of the original CM program file with the
translation of that code appended on to the end.  This has the advantage
that the CM program itself is still a valid (though typically 10x larger) CM
program file, and as such can be run on either a Classic 3000 or a PA-RISC
system.  This is the primary reason why OCTed programs retain the CM "PROG"
filecode.  The loader on MPE/iX recognizes the translated code and know how
to invoke it when you run a PROG file that has been translated.

Because all that translation does is to streamline the emulation process,
the functionality of an OCTCOMPed program will be identical to the
untranslated version.

There is a cost for translating with OCTCOMP due to the increased disk space
requirements and a potential performance cost due of the increased locality
size of the executing program which requires more memory and cache space
than the CM code.

One of the authors of OCTCOMP once told me he suspected there were cases
where untranslated code could be faster because the CM code to be emulated
together with the emulator code itself might fit within the CPU cache
whereas the translated code alone might not.

G.