Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dg!cheshirecat!lewine From: lewine@cheshirecat.rtp.dg.com (Donald Lewine) Newsgroups: comp.arch Subject: Re: Interrupts in user space Message-ID: <977@dg.dg.com> Date: 17 Sep 90 17:17:41 GMT References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM> Sender: root@dg.dg.com Reply-To: uunet!dg!lewine Organization: Data General Corporation Lines: 33 In article , moss@cs.umass.edu (Eliot Moss) writes: |> While we're on the subject, a user-implemented flavor of system call is nice, |> too. I'm thinking of something akin to the PDP-10 UUO (unimplemented user |> operation) instruction. A short instruction that calls through a vector. This |> is essneitally a call to a global subroutine, but exactly which subroutine it |> is can be changed dynamically (by changing the vector), and the instruction |> fits into substantially fewer bits. Funny, that is exactly the problem we were trying to fix with the VAX! The *caller* should not need to know if he is calling the kernel or another subroutine. It is far more likely to move a function into the kernel for speed or into user space than to want to change the library function on the fly. The problem with the UUO (or EMT on the PDP-11) is that the compiler had to know which routines were called with a CALL and which with a UUO. [The alternative is a call to a routine which does a UUO. That does not provide the speed advantage you want!] It is far better to use the RISC scheme of making all calls small and fast than to make a selected few into UUOs. BTW, If you do want to call a dyncmically changing subroutine CALL @vector works just fine. -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com