Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!ucsd!ucsdhub!hp-sdd!hplabs!hpl-opus!hpccc!culberts
From: culberts@hpccc.HP.COM (Bruce Culbertson)
Newsgroups: comp.sys.nsc.32k
Subject: Some architecture questions
Message-ID: <5980003@hpccc.HP.COM>
Date: 5 Aug 88 19:40:08 GMT
Organization: Hewlett-Packard Co.
Lines: 27

I recently noticed a few features of the NS32000 architecture which
I do not understand.   Maybe someone could enlighten me.

Why doesn't the SVC (supervisor call) instruction advance the program counter
to the next instruction before pushing it onto the stack?  Leaving the PC
unchanged makes sense for some traps, where the user will usually want to
retry the instruction causing the trap.  With SVC however, the user wants to
continue with the next instruction after the call has completed.  As
implemented, SVC is not a call in the usual sense.  In contrast, the trace
trap does do the expected thing; i.e. it advances the PC before pushing
it onto the stack.

Second, why don't the traps clear the interrupt enable flag?  If the flag were
cleared and the user wanted interrupts to remain on, he could easily turn
them back on with only a few microseconds lost.  With interrupts remaining
on at the beginning of a trap, an important interlock is hard to achieve.
The problem arises with multiple (nested) interrupts and traps.  The outer
(first) interrupt/trap should save the user state in a process table and
restart a user process upon returning.  Inner interrupts should merely save
the running state and restore it upon returning.  If interrupts were disabled
on traps and interrupts, trap/interrupt handlers could increment a semaphore
with which they could determine if they were inner or outer.  With interrupts
enabled, the semaphore cannot be implemented because another interrupt can
sneak in before the semaphore is incremented.  What solutions have operating
system implementers found?

Bruce Culbertson
culberts@hplabs.hp.com