Shmuel Metz , Seymour J. wrote:
That's still wrong. The SVC instruction caused an interrupt, period.
It was up to the SVC SLIH to index into the SVC table, etc. There was
no SVC Assist feature on the S/360.
To add to the fun, CP/67 and VM used the Diagnose instruction as a
means for a problem[1] program to cause an interrupt to invoke a
supervisor state routine. The handling was a direct parallel to the
SVC FLIH and SLIH in OS/360; CP had to determine that the interrupt
code was 2, the virtual machine was in virtual supervisor mode and the
opcode was DIAG, then use the DIAG code as an index to the proper
routine.
[1] But virtual supervisor mode.
CP67 on svc interrupt ... had to determine if the svc old psw was in
supervisor state or problem state. if problem state ... a virtual
machine was running ... and then had to go off and reflect an emulated
svc interrupt to the virtual machine. If the svc old psw was in supervisor
state, it was the cp kernel running ... and it had to go off and perform
the function for 0, 4, 8, and 12; mostly "8" which was internal kernel call
and "12" which was internal kernel return.
CP67 on program interrupt ... had to determine if the program old psw
was in supervisor state or problem state ... if supervisor state
... it was a CP67 kernel problem. If the program old psw was problem
state then the virtual machine was running. If it was program
interrupt for privilege instruction and the virtual machine was in
virtual supervisor state ... then the kernel had to emulate the
privilege instruction ... otherwise it emulated a program interrupt to
the virtual machine. For emulation of a privilege instruction, the
kernel had to determine the opcode of the interrupting instruction
... and effectively use decode table for which instruction decode
routing to go off to.
Three people from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
had come out and installed cp67 the last week in jan68 at the univ.
where i was undergraduate.
That spring and summer I had done a lot of rewrite of the cp67 kernel.
The CP67 kernel used svc 8/12 interrupts for all calls between
internal routines. I rewrote it to cut the processing from about
300mics (per call/return) down to about 80mics. I also implemented a
virtual machine SVC "fastpath" reflect (to the virtual machine)
completely within the kernel SVC FLIH which substantially reduced that
pathlength. As previously mentioned I gave a talk at the aug68 share
meeting in boston on some of the results ... recent posts:
http://www.garlic.com/~lynn/2007b.html#45 Is anyone still running
http://www.garlic.com/~lynn/2007c.html#45 SVCs
as mentioned in above ... i then changed the internal linkage for
various high-use kernel routines from SVC (interrupt) to straight
BALR.
Somewhere along the way ... I started looking at overhead in CMS
virtual machine ... and noticed that all the disk i/o operations were
effectively done syncronously ... i.e. CMS would do SIO for the disk
I/O and then LPSW into wait state waiting for the disk I/O to
complete. CMS never attempted to any overlapped processing while
waiting for disk i/o. Also, one of cp67 big overhead, long path items
was channel program (CCW) i/o decode and emulation.
So I added some code to CMS that would double check if it was running
in a virtual machine (the CP67 CMS could also run on bare real
hardware), and if so ... instead of doing a regular disk I/O CCW
sequence ... it would do a special disk CCW with x'FF" opcode
... which had parameter list for seek, search, and read/write ... and
if chained for multiple record transfer. The x'FF' CCW opcode was
special case to quickly decode and emulate and was also defined to be
"immediate" ... i.e. the virtual SIO wouldn't complete until the disk
I/O had finished ... and then it would complete with condition code
one on the SIO (i.e. immediate, csw stored). That also eliminated the
additional internal CMS processing, the virtual LPSW instruction
emulation as well as the virtual I/O interrupt emulation. This cut
typical cp67 supervisor emulation overhead for CMS virtual machine by
well over half (in addition to the other stuff that I had already done
... and also showed up in the os/360 mft14 benchmarks).
The people at the science center (primarily Bob Adair) explained to me
in gory detail that I wasn't allowed to do that ... since it violated
the purity of the virtual machine architecture (i.e. the channel
program architecture was not defined to do what I had defined for the
x'FF' opcode). However, everybody liked the resulting performnace
improvement benefit. So it was explained that there was this
"diagnose" instruction which was described in the 360 principle of
operations to be "model" dependent ... and so it would be possible to
define the abstraction of a "virtual machine" model ... and when
running a 360 "virtual machine" MODEL ... cp67 could define how the
diagnose instruction worked anyway it wanted to. So the code I had
done for SIO disk x'FF" CCW got remapped into the diagnose instruction
(with the definition for the diagnose instruction to sort of be like
SVC kernel call with function codes selecting which operation was to
be performed).
misc. past posts mentioning diagnose instruction
http://www.garlic.com/~lynn/99.html#95 Early interupts on mainframes
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling
convention
http://www.garlic.com/~lynn/2002h.html#62 history of CMS
http://www.garlic.com/~lynn/2003.html#60 MIDAS
http://www.garlic.com/~lynn/2003m.html#36 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#9 virtual-machine theory
http://www.garlic.com/~lynn/2003p.html#40 virtual-machine theory
http://www.garlic.com/~lynn/2004.html#8 virtual-machine theory
http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY
OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE
http://www.garlic.com/~lynn/2005b.html#38 Relocating application architecture
and compiler support
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005o.html#35 Implementing schedulers in
processor????
http://www.garlic.com/~lynn/2005t.html#8 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006w.html#29 Descriptive term for reentrant
program that nonetheless is
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
