HP3000-L Archives

July 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Cooper <[log in to unmask]>
Reply To:
Steve Cooper <[log in to unmask]>
Date:
Thu, 8 Jul 1999 16:21:02 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
On Thu, 8 Jul 1999 09:37:34 -0400 , Stephen Douglass
<[log in to unmask]> wrote:

>This is an "out of curiosity" question: when NM-to-CM switch occurs (and
>vice versa), what is actually going on?  Is the actual PA-RISC chip
>detecting a CM instruction and invoking a different chunk of circuitry, is
>some (using IBM lingo) microcode performing the CM instruction, or is some
>other software performing the CM instruction?

It is all done with mirrors.  There is absolutely no support for CM
instructions in PA-RISC, only the NM ones.  When you "run" a CM
program, you are really running the emulator, an NM program, which
reads a CM instruction and then executes the proper NM instructions to
emulate it.  When you OCT (Object Code Translate) a program, it is
still in CM.  The difference is that the emulating NM instructions,
after a round of optimization, are appended to the end of the CM code
in the program file.  When the emulator notices an active OCT'ed
segment, rather than the normal FETCH-DECODE-EMULATE cycle, it just
starts executing the translated NM instructions instead.  You are
still in CM at that point, with all of the old machines' limitation;
the code just executes faster.

Hope this demystifies a bit,

Steve

ATOM RSS1 RSS2