Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!harrier.ukc.ac.uk!zodiac.ukc.ac.uk!cur022
From: cur022%cluster@ukc.ac.uk (Bob Eager)
Newsgroups: comp.os.misc
Subject: Re: Call Gates vs. traps
Message-ID: <22184.27fcc472@cluster@ukc.ac.uk>
Date: 5 Apr 91 18:39:46 GMT
References: <1991Apr3.073617.1167@ibmpcug.co.uk>
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 23

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
-------------------------+-------------------------------------------------