dylan@ibmpcug.co.uk (Matthew Farwell) (04/03/91)
This is a simple enough question. (The answer won't be though). Multics and OS/2 use Call Gates to implement system calls, whereas the rest of the universe uses traps, yes? What are the advantages/ disadvantages of using Call Gates over traps? (This isn't a homework question, in case you were wondering). p.s. Can anyone tell me how to get any references on Multics? Dylan. -- Matthew J Farwell: dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan If you've ever wondered how to get triangles from a cow, you need butter, milk and cheese and an equilateral chainsaw.
barmar@think.com (Barry Margolin) (04/05/91)
In article <1991Apr3.073617.1167@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >Multics and OS/2 use Call Gates to implement system calls, whereas the >rest of the universe uses traps, yes? What are the advantages/ >disadvantages of using Call Gates over traps? The main advantage is that the same mechanism is used to call system routines as library routines. It also generalizes to multiple protection levels, whereas system calls are normally only good enough when there are only two protection levels (user and system). Multics has eight nested rings of protection, and gates are used whenever a program wants to call into a more privileged level. >p.s. Can anyone tell me how to get any references on Multics? The only easy-to-find reference is the book on Multics by Organick, published by the MIT Press. Other than that, you'll have to find papers from technical conferences in the mid- to late-60's. The book probably contains a bibliography that points out these papers. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
sef@kithrup.COM (Sean Eric Fagan) (04/05/91)
In article <1991Apr3.073617.1167@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >Multics and OS/2 use Call Gates to implement system calls, whereas the >rest of the universe uses traps, yes? What are the advantages/ >disadvantages of using Call Gates over traps? Multics and OS/2 use call gates because the hardware is capable of doing that. For example, unix for the '386 also uses call gates (call 0x7,0; it's a simple call gate, true, but it's a call gate nonetheless). Most processors have a 'syscall' or 'trap' instruction to do that; *nix tends to use that; *nix for the '386 doesn't use the INT instructions which are the closest moral equivalent, but the call gates instead. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
efeustel@prime.com (Ed Feustel) (04/06/91)
Call gates can be considerably faster than traps which may require substantial interpretation. We use call gates on the Prime 50 series. When one proceeds to an inward ring, the stack changes and the access writ rights are changed automatically. Depending on how much saving and interpretation is done and on how well the call gates are implemented (not very well on the 386) call gates can be the prefered method of implementation of system calls.
cur022%cluster@ukc.ac.uk (Bob Eager) (04/06/91)
In article <1991Apr3.073617.1167@ibmpcug.co.uk>, dylan@ibmpcug.co.uk (Matthew Farwell) writes: > Multics and OS/2 use Call Gates to implement system calls, whereas the > rest of the universe uses traps, yes? What are the advantages/ > disadvantages of using Call Gates over traps? The ICL 2900/3900 also uses the equivalent of call gates; the ICL OS called VME uses these and so did a homebrew OS called EMAS that I worked on. Not to mention OS/2... Call gates give you a procedural interface to system calls; interrupts don't. This means that high level languages can call the system directly without having to call a tiny kludge module that generates the interrupt. Most hardware implementations of call gates also check that the correct number of parameters have been stacked, and even copy them to the new stack when a stack switch takes place. With call gates, the calling code doesn't need to know if it is calling a library routine or a system call. This gives opportunities for implementing a call in different ways on different systems. -------------------------+------------------------------------------------- Bob Eager | University of Kent at Canterbury | +44 227 764000 ext 7589 -------------------------+-------------------------------------------------
mac@eleazar.dartmouth.edu (Alex Colvin) (04/06/91)
Call gates don't require modification of the operating system - anyone can publish their gates. Gates support more of a peer-peer call interface. Traps are usually fixed in hardware & owned by the OS. Defining a trap consumes a global resource. Traps support user/kernel calls. On systems with protection the set of traps is usually fixed. On systems without, such as PCs & Macs, there are often conflicts over who uses which trap.
edwardj@microsoft.UUCP (Edward JUNG) (04/07/91)
In article <1991Apr5.075057.16322@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <1991Apr3.073617.1167@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >>p.s. Can anyone tell me how to get any references on Multics? > >The only easy-to-find reference is the book on Multics by Organick, >published by the MIT Press. _The_Multics_System_, Elliott Irving Organick, MIT Press, 1972 ISBN 0-262-15012-3 The original project goals, a cooperative effort between Bell Labs, GE, and MIT, were outlined in the American Federation of Information Processing Societies Conference Proceedings, Volume 27, Part 1, 1965 Fall Joint Computer Conference, Washington, DC (Spartan Books, 1965), pp. 185-247. There is also the "Multics System Programmers Manual", but I don't know where you can get this from these days. -- Edward Jung Microsoft Corp. My opinions do not reflect any policy of my employer.
guy@auspex.auspex.com (Guy Harris) (04/10/91)
>With call gates, the calling code doesn't need to know if it is calling >a library routine or a system call. This gives opportunities for implementing >a call in different ways on different systems. With dynamic linking, the calling module doesn't need to know if it's calling a routine that's just a tiny kludge module that generates a trap, or a routine that does more. This gives opportunities for implementing a call in different ways on different systems, and having the same executable images run on those different systems (if you're willing to require people to relink their programs, you don't even need dynamic linking, much less call gates, so I assume you meant that you can implement calls in different ways and have the same binaries work). You don't *need* call gates for that (which is nice, given that many of the processors upon which systems supporting those flavors of dynamic linking are implemented don't *have* call gates).