Subject: Re: Question re timesharing option behavior

From: [email-masked] (Megan)
Date: Sat, 4 Dec 1993 11:05:48 GMT

jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:

>When the computer is operated in user mode, operation is normal except
>for IOT, HLT, LAS and OSR instructions.  When one of these instructions
>is encountered, the hardware inhibits the normal instruction sequence
>(other than rewriting the instruction in memory), and generates an
>interrupt at the end of the current memory cycle by setting the UINT
>flip-flop.  The time-sharing system's monitor program then analyzes the
>source of the interrupt, and takes appropriate action.

>This suggests that PC should not be incremented by the fetch of a
>prohibited instruction, and that no side effects such as CLA or skips
>take place in the case of microcoded combinations with OSR or HLT.
>When you think about it, it would be impossible for the interrupt
>service routine to respond correctly to the interrupt if the PC were
>allowed to change to point to anything other than the instruction that
>caused the interrupt, because then any code to analyze the cause of
>the interrupt would be hopelessly confused.

I've been thinking about such occurrances which cause special code to
be processed like this.  Since this is an emulator, you can take one
of two different courses - 1) Make it as similar to a real machine,
including all idiocyncracies or 2) Try to clean up, in emulation, the
operation of the machine.  I think this is one of those cases where
doing some clean-up in design might not be destructive to the
emulation.  If the emulation processes an instruction completely
before responding to an interrupt, you could always pretend that the
interrupt didn't happen until the instruction completed anyway...

					Megan Gentry

---

From: [email-masked] (Charles Lasner)
Date: 8 Dec 1993 06:15:21 GMT

>interrupt didn't happen until the instruction completed anyway...

A simple form of the answer: if you change the hardware (whether emulated or
not!) you break the software.  Lotsa stuff written to handle this problem
already works fine, being only slightly fooled by trick sequences such
as SKP HLT;HLT where the SKP part may be a conditional, and it's hard to trace
back the exact PC value, etc.  (Note: this only affects status reports of the
halt, thus the exact PC value is subject to a +/-1 error worst case; when 
execution continues, all runs properly, etc.)

cj (if it ain't broke, don't fix it) l

---

From: [email-masked] (Megan)
Date: Thu, 9 Dec 1993 00:08:17 GMT

>execution continues, all runs properly, etc.)

But keep in mind, the probability of executing an instruction without
an interrupt is hopefully much higher than executing one that is
interrupted.  Therefore, if you process the instruction as if no
interruupt had occurred, that operation will be correct.  If you then
process the interrupt (as if the interrupt HAD happened between
instructions), THAT operation should work correctly as well.

As for the example (SKP HLT;HLT) which you posit, I was under the
impression (probably faulty) that the PC is incremented at the end of
an instruction.

					Megan Gentry

---

From: [email-masked] (Charles Lasner)
Date: 11 Dec 1993 06:08:58 GMT

>impression (probably faulty) that the PC is incremented at the end of

All this is irrelevant.  The only uncertainty is reporting exactly *where* in
memory a HLT occurred should it want to be reported at all.  Assuming the user
wants to continue from the halt, just dismiss the interrupt.  The machine
continues.  The interrupt handler for the UINT has to determine why it's been
enterred.  OSR services will be handled normally according to some convention
and the HLT part will either be continued or aborted/restarted from a
designated starting address.

In any case, the original issue was that the -8 design shouldn't be changed,
whether emulated or real.  There isn't enough concern for this nebulous
point to bother.

cjl

---

From: [email-masked] (Megan)
Date: Sun, 12 Dec 1993 06:18:02 GMT

[email-masked] (Bob Supnik) writes:

>On a PDP-8 with the timesharing option installed, and user flag = 1:

>1. When an IOT is decoded, an interrupt occurs.  Does the saved PC in
>   location 0 point at the IOT, or the next instruction?

>2. When an OSR or HLT is decoded, an interrupt occurs.
>   a) Does the saved PC in location 0 point at the operate, or the
>      next instruction?
>   b) Are the other parts of the operate (including the skips) executed
>      or nop'd?

I think I found the answer.  According to the manual I have, the PC
is incremented after an instruction is read from memory.  More
specifically, it is incremented (on a pdp-8/e) during time state 1
(ts1) of the fetch cycle, apparently before the instruction has
actually been fetched because it uses a secondary internal register
(cpma) to point to the address to read.

Also according to the book I have, the interrupt request line is
polled during ts4 of every memory cycle in which execution of an
instruction occurred.

During ts4 of every machine cycle:
(note: yes falls through)

	1) about to enter fetch?
	   n) finish current instruction
	2) is interrupt system on?
	   n) begin next instruction
	3) is interrupt request line asserted?
	   n) begin next instruction
	4) set ir = 4
	5) set cpma = 0
	6) enable execute state
	7) processor turns interrupt system off
	   and executes jms 0 instruction

Basic instructions have up to three states (fetch, defer and execute, 
each with 4 time states), IOT and operate instructions have only one 
state (fetch, also with 4 time states).  Since the PC is incremented at 
the start of fetch, and the interrupt request line is polled at the end 
of each state (fetch/defer/execute), I would say that the contents of 
location 0 during an interrupt would point to the instruction following
the IOT/OPR.

					Megan Gentry
					Former RT-11 Developer

---

From: [email-masked] (Charles Lasner)
Date: 13 Dec 1993 22:39:28 GMT

>>On a PDP-8 with the timesharing option installed, and user flag = 1:

**** AND interrupts are enabled! ****

>>   location 0 point at the IOT, or the next instruction?

The IOT action is inhibited, thus it can't skip, so it points to the next.

>>   a) Does the saved PC in location 0 point at the operate, or the

Always the next, unless a skip occurred in which the one following that.

>>   b) Are the other parts of the operate (including the skips) executed

All else works regardless, and thus might skip if appropriate.

>(cpma) to point to the address to read.

Correct.  The PC is always (at least) incremented to point to the next.  If a
JMP of SKP happens, then it will change, but not yet at the earlier phase of
an instruction, etc.

>polled during ts4 of every memory cycle in which execution of an

Correct.  Keyword here is EXECUTE.

>	   n) finish current instruction

Correct.  Instructions, once started - will finish!

>	   n) begin next instruction

Correct.  No interrupts unless enabled.  (Also not default!)

>	   n) begin next instruction

Yes, an interrupt can be acknowledged.

>	4) set ir = 4

Yes, fake JMS.

>	5) set cpma = 0

Yes, fake JMS 00000.

>	6) enable execute state

Needed to allow extended memory considerations to finish as well!

>	   and executes jms 0 instruction

Correct.  Interrupt routines start in 00001, and are themselves interrupt-
immune!

>of each state (fetch/defer/execute), I would say that the contents of 

Wrong, only on EXECUTE.  A started instruction always finishs.  That's why
they talk about interrupt latency for long EAE instructions!

>location 0 during an interrupt would point to the instruction following

In the sense you ask, yes, but still not correct.  The instruction could be
SPA CLA HLT.  If HLT follows it, is the PC updated because the SPA made it
skip?  You can't tell since the AC is now cleared.  However, all this means
is you have to look at the last two instructions to figure it out.  The worst
thing is that you could misinform about exactly where the HLT occurred, or in
some bizarre case, fail to update the OSR information.  But certainly, it never
points to the trapped instruction, only to after it.  The question is how far.

>					Former RT-11 Developer

cjl (Current P?S/8 Developer)

---

From: [email-masked] (Greg Ewing)
Date: Mon, 13 Dec 1993 01:37:48 GMT

In article <[email-masked]>, [email-masked] (Megan) writes:
|> Therefore, if you process the instruction as if no
|> interruupt had occurred, that operation will be correct.

That's true for externally-generated interrupts, but this discussion
is about traps which occur as a result of encountering a "privileged"
instruction while in "non-privileged" mode. In that case, the
exact behaviour of the hardware must be replicated, because
software depends on it.

>From what's been said, it seems that the correct behaviour is
*not* to execute the trapped instruction (that's the point of trapping
it, after all), with the return address equal to the address of
the trapped instruction plus one.

The latter is important because the trap handler may want to find
the instruction that caused the trap, so it can decide what action
to take.

I've used the word "trap" instead of "interrupt" to make it clearer
that we are talking about a synchronous rather than an asynchronous
event.

|> 					Megan Gentry

- Greg

---

From: [email-masked] (Charles Lasner)
Date: 14 Dec 1993 16:09:00 GMT

In article <[email-masked]>,
>exact behaviour of the hardware must be replicated, because

Exactly correct.  This is not a discussion on the need to maintain
"transparency" through the course of normal interrupts.  That applies in any
and all interrupt-driven code.  This is a discussion of the specifics of
user mode as implemented with the time-share trap hardware.

>the trapped instruction plus one.

Correct.  All the software written expects the interrupted PC to have already
been updated.  There is no valid discussion regarding "correcting" it since
that's an officially recognized and expected behavior.  A few rounds ago I
first joined in with "if it ain't broke, don't fix it".

>the instruction that caused the trap, so it can decide what action

Correct.  The classic example is where the execution of standard IOT's relative
to the normal 03/04 console can be faked out to respond to the actual hardware
status of the user's console on a TSS8 system where the user's hardware isn't
03/04 at all, but rather a channel of a DC02 or whatever.  This satisfies
compatibility with stand-alone software run on the time-sharing system, etc.

However, there is an actual problem, although somewhat contrived.  The first
half of the problem has to do with disposition of a HLT operation.  In the
case of something like SKP HLT;HLT, it's not precisely possible to indicate the
last executed instruction, since a JMP to the HLT could have occurred.  A
similar situation exists where the first could be something like SPA CLA HLT.
This is because the CLA has obliterated the means to be certain of whether the
following HLT was/wasn't skipped.  In any case, the only consequence of any of
this is the imprecise statement of last instruction executed, and a copout is
possible: just merely display the restart address.  That info is always correct
for all scenarios of this type.

The second half is more serious.  Should OSR be included in what might have
executed, you could be misled into improper handling of it.  For example, it's
not possible to determine whether or not to emulate the switch register if the
sequence SPA CLA OSR HLT;HLT is given because the HLT could've been JMP'ed to
instead of skipped over by the successful skip operation because the AC was
positive before execution.  The CLA makes the AC clear so you can't tell if
perhaps the AC was actually negative and the HLT wasn't actually skipped.  Of
course if the AC is non-zero, you do know that the HLT *was* JMP'ed to, etc.

IMO, anyone who uses these "trick" sequences gets what they deserve.  There
really isn't much call for conditionally skipping over an OSR operation, and
in an emulator or time-shared version, it isn't necessary to placate such
nonsense anyway.

So, in summary:

Time-share trap systems cannot report the last executed instruction under
some circumstances, but can always restart after a HLT correctly.  This
behavior is incidentally shared by the DECmates other than DM I.

Trick sequences involving OSR in combination with conditional skips in
combination with CLA in combination with an adjacent trappable instruction
should ignore the OSR or complain about it as a "violation" of the
time-share environment.

The significence of this tempest-in-a-teapot is so slight that no attempt 
should be made to "correct" it.

>that we are talking about a synchronous rather than an asynchronous

Correct.  There is no place in this discussion for anything remotely to do with
conventional interrupt handling.  The user interrupt is a trap that immediately
causes entry into the UINT handler; all other interrupts are only entered when
the external devices are acknowledged between instructions.

cjl

---

From: [email-masked] (Megan)
Date: Tue, 14 Dec 1993 01:26:58 GMT

>they talk about interrupt latency for long EAE instructions!

Right, I had meant to get that across, but failed.  I meant to say
that if the instruction is an OPR or IOT instruction, the check
mentioned in my previous mail occurs at the end of the fetch cycle.
If it is a basic instruction, the check would occur at the end of
the execute cycle.  At least this is how I understand it.  The key
being "in the cycle in which an instruction is executed".

					Megan Gentry