Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!julius.cs.uiuc.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: new SB-prolog diffs for DG (& probably other m88k) machines Keywords: m88k prolog patches sb-prolog dei Message-ID: <3729@goanna.cs.rmit.oz.au> Date: 11 Sep 90 09:32:53 GMT References: <3653@goanna.cs.rmit.oz.au> <1990Sep1.170632.13330@cs.umn.edu> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 27 In article <1990Sep1.170632.13330@cs.umn.edu>, martin@cs.umn.edu (Johnny Martin) writes: > In article <3653@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >SB Prolog itself doesn't need 'syscall' in its full generality. > >If someone wants access to a particular system call that isn't numbered > >in the SB Prolog manual, they can add their own case to the switch() that > >I am proposing. That's the advantage of having sources. > In sbprolog, there is a limit on the number of builtins. You weren't paying attention. I was saying KEEP the SB-Prolog predicate syscall and the C function that backs it up, BUT have it go through a switch() that calls each of the necessary system calls explicitly. That is, eliminate calls to the ***C*** function syscall(). The number of builtins isn't relevant. That doesn't need to change. > but at least using syscall.h should make it a bit more portable. No. Some of the functions one wants to call may be syscalls() in some flavours of UNIX (and thus be accessible through syscall()) but be library functions in other flavours of UNIX (and thus not have syscall() numbers assigned to them). [alarm(), time(), and nice() spring to mind.] In particular, note that DEC are said to be promising a POSIX-compliant interface to VMS; syscall() is *not* part of IEEE 1003.1 at all (nor, for that matter, is it in the SVID). -- Heuer's Law: Any feature is a bug unless it can be turned off.