Charles, isn't this "Mid-Instruction Fault", rather than "Mid-Instruction
Interrupt"?
AL39 uses fault and interrupt somewhat ambiguously; the hardware processes
them in very similar ways, so the ambiguity is not overly harmful. Grepping
through AL39:
On Sun, Dec 25, 2016 at 4:12 PM, Eric Swenson eswenson1@users.sf.net
wrote:
Charles, isn't this "Mid-Instruction Fault", rather than "Mid-Instruction
Interrupt"?
AL39 uses fault and interrupt somewhat ambiguously; the hardware processes
them in very similar ways, so the ambiguity is not overly harmful. Grepping
through AL39:
Status: open
Milestone: MCRB
Created: Sun Feb 14, 2016 07:25 PM UTC by Charles Anthony
Last Updated: Mon Dec 26, 2016 12:12 AM UTC
Owner: Charles Anthony
I interpret it differently. It is MIF and not MFI, and I would suggest the
acronym stands for Mid-Instruction Fault.
Down the rabbit hole we go. Looking at azm_display_mc_.pl1:
if scu.ir.mif then
eis_info_valid = "1"b;
else eis_info_valid = "0"b;
this would imply that if MIF is set, then an EIS instruction was running.
Back to AL39:
MULTICS PROCESSOR FEATURES
Capability to interrupt program execution in response to an external
signal (e.g., I/O
termination) at the end of any even/odd instruction pair (midinstruction
interrupts are
permitted for some instructions)
and the definition of the bit in the SCU register description:
m Mid instruction interrupt fault:
This indicator is set OFF at the start of execution of each
instruction and is set ON by the events described below. The
indicator has meaning only when determining the proper restart
sequence for the interrupted instruction. This indicator can be
set on:
...
(2) By an interrupt signal during execution of those EIS
instructions that allow very long operand strings.
So, in general, the bit being set means that the instruction is resumable;
this only makes sense for the EIS instructions that are driven by CHTALLY;
ie iterate over the operand, and "resume" means take up where you left off
in the iteration.
So the instruction can be suspended by an access violation, directed fault,
or a pending external interrupt; the interrupt case is unique the these
"long operand" instructions, for all other cases the interrupt pending
signal is sampled just before instruction fetch.
(The I/F bit is also set or cleared to indicate if the exception was an
interrupt or a fault)
So MIF can be set be either a fault or interrupt,and the fact that is set
for those special cases of an interrupt makes me prefer the "interrupt"
interpretation.
-- Charles
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Charles, isn't this "Mid-Instruction Fault", rather than "Mid-Instruction Interrupt"?
On Sun, Dec 25, 2016 at 4:12 PM, Eric Swenson eswenson1@users.sf.net
wrote:
"Midinstruction fault: 0 occurrences.
"Midinstruction interrupt" 4 occurrences
"Mid instruction interrupt fault" 5 occurrences
Hmm. I'm 0 for 9.
I opine that the 'I' in MFI is 'interrupt' (as opposed to 'instruction'),
so I fee "Mid-instruction Interrupt Fault" is the correct deacronymization.
-- Charles
I interpret it differently. It is MIF and not MFI, and I would suggest the acronym stands for Mid-Instruction Fault.
Gary?
-- Eric
Related
Tickets:
#100On Mon, Dec 26, 2016 at 10:12 AM, Eric Swenson eswenson1@users.sf.net
wrote:
this would imply that if MIF is set, then an EIS instruction was running.
Back to AL39:
MULTICS PROCESSOR FEATURES
signal (e.g., I/O
termination) at the end of any even/odd instruction pair (midinstruction
interrupts are
permitted for some instructions)
and the definition of the bit in the SCU register description:
m Mid instruction interrupt fault:
This indicator is set OFF at the start of execution of each
instruction and is set ON by the events described below. The
indicator has meaning only when determining the proper restart
sequence for the interrupted instruction. This indicator can be
set on:
...
(2) By an interrupt signal during execution of those EIS
instructions that allow very long operand strings.
So, in general, the bit being set means that the instruction is resumable;
this only makes sense for the EIS instructions that are driven by CHTALLY;
ie iterate over the operand, and "resume" means take up where you left off
in the iteration.
So the instruction can be suspended by an access violation, directed fault,
or a pending external interrupt; the interrupt case is unique the these
"long operand" instructions, for all other cases the interrupt pending
signal is sampled just before instruction fetch.
(The I/F bit is also set or cleared to indicate if the exception was an
interrupt or a fault)
So MIF can be set be either a fault or interrupt,and the fact that is set
for those special cases of an interrupt makes me prefer the "interrupt"
interpretation.
-- Charles
MCR10016 created for this ticket.
Fix has been installed on GHM and will be part of next Multics release.
Closing as ticket moved here: http://multics-trac.swenson.org/ticket/28