Talk:Supervisor Call instruction

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by Computer hardware task force (assessed as Low-importance).

Split or retitle

This article should either be split into separate pages for SVC instruction and SVC routine, or the title and contents should be revised to reflect the dual coverage. Shmuel (Seymour J.) Metz (talk) 00:38, 1 June 2010 (UTC)[reply]

Hmm. The page for Ring (computer security) discusses both rings *and* {supervisor,kernel,master} mode/{problem,user,slave} mode. In the x86, those two concepts might be the same, and maybe you could argue that the VAX had four rings corresponding to the four processor modes - but the Honeywell 6180 had both rings and master mode; the vast majority of Multics code, including ring 0 code, ran in slave mode, with tiny stubs, callable only from ring 0, to execute master-mode-only instructions.

I'm not sure whether there should be separate pages for rings and processor modes, or whether the Ring (computer security) page should handle both. In either case, perhaps the general concept of a "trap to privileged mode" instruction should be discussed on the page that discusses processor modes, and a separate page be used to discuss how privileged-mode code works in OS/360 and successors. Guy Harris (talk) 03:21, 6 September 2010 (UTC)[reply]

Use of term kernel

The term kernel does not apply to OS/360 through z/OS; the supervisor is orgamized in a radically different form from that implied by kernel in academic circles. E.g., there is pagable code running in key 0 Supervisor State. some of which does callbacks to Problem State. —Preceding unsigned comment added by Chatul (talk • contribs) 00:58, 1 June 2010 (UTC)[reply]

I don't believe that the notion of an OS kernel implies that the kernel code must be non-pageable. (And isn't "key 0" separate from "supervisor state"? Can't problem state code run with storage key 0?) Guy Harris (talk) 00:24, 5 September 2010 (UTC)[reply]

Yes, the PSW key and the PSW mode are separate. OS/360 and successors have code that is problem state key 0 and also code that is supervisor state user key. Further, the nucleus includes code that executes in the key and mode of the caller. There is no physical separation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:05, 5 September 2010 (UTC)[reply]

Clarifications of my recent edit

My recent edit was intended to correct several overly broad statements in the article. While I added some links for clarity, I did not attempt to split, expand or restructure the article.

The SVC instruction did not exist on IBM mainframe computers prior to the System/360.
The SVC instruction does nothing more than to cause an interrupt; the other functionality attributed to it actually pertains to the operating system.
The description of SVC types is specific to OS/360 and successors.
Type 6 SVC's came later, and had nothing to do with being user defined; the installation could add its own SVC's of any type.
While SVC was used in OS/360 as the only means for problem programs to call privileged services, MVS/SP added the use of Program Call (PC), and in z/OS the SVC linkage is used mostly for legacy interfaces. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:23, 6 September 2010 (UTC)[reply]

Intel equivalent?

My understanding is that of the three Intel instructions that Guy Harris added, only INT is similar to SVC; I believe that SYSCALL and SYSENTER are more complicated instructions that do not cause interrupts. Also, I believe that SYSCALL is Advanced Microdevices (AMD), not Intel.

If this understanding is correct, then the reference to INT should remain where it is but the references to SYSCALL (AMD) and SYSENTER (Intel) should be moved to notes on the Program Call (PC) instruction. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:49, 6 September 2010 (UTC)[reply]

Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, N-Z describes both SYSCALL and SYSENTER. SYSCALL is 64-bit only; SYSENTER is available in 32-bit and 64-bit mode. They're somewhat like traps in that they switch from ring 3 to ring 0, switch the code and stack segments, and jump to a specific location; the difference is that the "switched to"/"jump to" information comes from model-specific registers rather than from a trap vector in memory, and the saved state also goes into registers. Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M describes INT - the description is a lot more complicated than the description of SYSCALL or SYSENTER.

Would you have time to do an article on the Intel 64-bit SYSCALL? Is it the same as the AMD SYSCALL? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:39, 7 September 2010 (UTC)[reply]

When it comes to instructions, the details of how privilege-mode/ring switching is done are processor-dependent in any case, so there aren't exact equivalents. Many of them, including SVC, INT, Alpha's Digital UNIX PALcode callsys, and, as I remember, MME, generate exceptions/traps/interrupts that behave similarly to external interrupts and other internal traps. Others, such as Program Call, SYSCALL, and SYSENTER, don't.

In any case, as per my earlier comments, I see at least three topics here:

the general notion of privilege levels and instructions to elevate privilege level and return from an elevate-privilege-level opeation;
the specific details of particular instructions, e.g. whether they use the machine's interrupt/trap mechanism;
the OS/360-and-successors supervisor call mechanism.

For this page, the first two paragraphs could be seen as covering items 1 and 2, the third and fourth paragraph cover item 3, the fifth paragraph I'd see as covering mainly item 1 (most OSes require some level of privilege to install privileged code), and the last paragraph mainly discusses OS/360 and successors. My inclination would be to put the stuff that discusses the OS/360-and-successors SVC mechanism into SVC (OS) or something such as that, and perhaps mention SVC, along with INT, SYSCALL, callsys, MME, etc. in a page such as Privilege level or Ring (computer security). (I think both of those pages require some work - Privilege level briefly introduces the concept and then proceeds to act as if the only computer architecture worthy of interest is x86, and Ring (computer security) looks a bit stitched together from discussions of Multics-like rings and user/kernel mode.) Guy Harris (talk) 00:30, 7 September 2010 (UTC)[reply]

And then there's CPU modes, which seems to be the page that makes a more general discussion of processor modes, and system call, which has a section discussing details of at least some of the privilege-elevating instructions. For all I know, there might be still others. Guy Harris (talk) 01:29, 7 September 2010 (UTC)[reply]

Had I written a new article called Supervisor call instruction I would not have included any of the OS/360 material; it belongs in OS/360 and successors. Currently I'm just trying to fix the egregious problems, rather than restructure the related articles.

MME is similar to INT and SVC; it simply causes a trap and the handling is up to the operating system, e.g., GCOS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:39, 7 September 2010 (UTC)[reply]

Rewrite lead

After trying and abandoning several revisions to this article I undertook to rewrite the lead paragraph and introduce some minimal sectioning in the rest. I eliminated the sentence on the PC instruction because I think it just confuses the issue. The article still has numerous problems — it is overly wordy and throws in extremely technical material with no definitions or explanation. Peter Flass (talk) 00:02, 12 September 2012 (UTC)[reply]

Nucleus, not resident control program

In OS/360 and successors the resident control program includes both the Nucleus (SYS1.NUCLEUS(IEANUCxx)) and the Link Pack Area (LPA). The heading in the table should be changed to indicate that a Type 1, 2 or 6 SVC must be in the Nucleus, not in the LPA. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:33, 26 December 2018 (UTC)[reply]

Removal of register information.

A recent edit by user:‎Peterh5322 removed the information on registers 3, 4 and 5 from the table. It also incorrectly describes register 15 as a linkage register rather than a parameter register. The contents of R3-R7 are listed below, where R6 and R7 are not relevant to OS/360.

R0 same as at time of SVC call
R1 same as at time of SVC call
R3 CVT address
R4 TCB address
R5 RB address
R6 Entry Point address (MVS)
R7 ASCB address (MVS)
R14 Return address
R15 same as at time of SVC call

Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:20, 30 July 2019 (UTC)[reply]