aglew@ccvaxa.UUCP (03/21/88)
..> The RPM-40's prefix instruction.
Some coding I've been doing recently has got me thinking
about the RPM-40's prefix instruction, used to generate
long literals.
Q: can an interrupt occur between the prefix and the instruction
that is being prefixed? On a page fault, where does the PC
point?
Reason: I'm writing some user mode trap code (don't ask) and I
keep running into the limited addressing range problem. Gould
Powernodes have only 16 bit offset fields; with base registers
you can address anywhere in memory, but when you don't have a base
register, eg. on a trap, you can only use BR0=0, meaning that you
can only address locations in the first 16 bit's worth, 64K,
of memory - locore.
I call this the "limited addressing range" variant of the
"limited literal size" problem. Some people call it the "base
register" problem, but in fact it occurs on any machine that
has a literal field less than a full size address - eg RISC I and II.
You can, of course, synthesize any arbitrary address by loading the high
part into a register, shifting, then loading the low part, but in trap
code you have to save at least one register before you can do this.
Since you can only do this into locore, locations in locore become a
rather precious resource. Managing that resource, for an OS, of course,
isn't too much trouble - but I want to write a trap routine that vectors
directly to user code with no OS intervention.
For the moment, I "steal" locore locations for a priviliged process;
for an unpriviliged process I have to assume base register usage
conventions, which reduces the generality of the code.
Even within the OS, managing locore has always seemed an unnecessary
pain to me.
The prefix instruction might seem to be the answer to this problem,
if an interrupt routine can generate an arbitrary address, using a
prefix, to store anywhere in memory. The prefix instruction would then
have to be stateless, hence uninterruptible.
I know, I'm making a mountain out of a molehill.oconnor@sungoddess.steinmetz (Dennis M. O'Connor) (03/24/88)
An article by aglew@ccvaxa.UUCP says:
] Some coding I've been doing recently has got me thinking
] about the RPM-40's prefix instruction, used to generate
] long literals.
]
] Q: can an interrupt occur between the prefix and the instruction
] that is being prefixed? On a page fault, where does the PC
] point?
Yes, this is allowed. "Where does the PC point" is to simple
a question for a pipelined machine : there are several
old PC values preserved on an interupt. I can't describe
RPM40 interupt handling yet due to contract limits, but
I will say that interupts can occur anywhere in a code
sequence (as can any other excpetion or surprise) and will be
properly handled : except for fatal errors, you will be able
to restart, as if the exception never occurred.
] ... "limited addressing range" variant of the
] "limited literal size" problem. Some people call it the "base
] register" problem, but in fact it occurs on any machine that
] has a literal field less than a full size address ...
]
] You can, of course, synthesize any arbitrary address ...
] but in trap code you have to save at least one register before you
] can do this ... managing that resource, for an OS, of course,
] isn't too much trouble - but I want to write a trap routine that vectors
] directly to user code with no OS intervention ...
]
] The prefix instruction might seem to be the answer to this problem,
] if an interrupt routine can generate an arbitrary address, using a
] prefix, to store anywhere in memory. The prefix instruction would then
] have to be stateless, hence uninterruptible.
The prefix instruction does solve your problem. It also totally
decouples instruction size from data-word size. However,
there is a state involved with prefixes ( after all, there's
no free lunch ) but it is managed by the hardware.
--
Dennis O'Connor oconnor%sungod@steinmetz.UUCP ARPA: OCONNORDM@ge-crd.arpa
( I wish I could be civil all the time, like Eugene Miya )
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)