Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!rutgers!ub.d.umn.edu!cs.umn.edu!martin
From: martin@cs.umn.edu (Johnny Martin)
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: <1990Sep1.170632.13330@cs.umn.edu>
Date: 1 Sep 90 17:06:32 GMT
References: <newton.652072040@smoggy> <3653@goanna.cs.rmit.oz.au>
Organization: University of Minnesota, Minneapolis - CSCI Dept.
Lines: 46

In article <3653@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>...
>It would be a service to humanity if _someone_ would remove 'syscall' from
>SB Prolog.  Before it dawned on me that SB Prolog had a GPL on it, I tried
>porting SB Prolog to a couple of machines, and 'syscall' was always
>seriously cathedralgic.  One of the reasons _why_ it is cathedralgic is
>that not only is 'syscall' a BSDism, the system call numbers themselves
>are *not* the same in all versions of UNIX.  That is, code which *uses*
>syscall() is not portable.
>

I sort of already did this.  I got frustrated trying to port sbprolog
to our sequent.  Actually, what I did was replace the hard-coded
syscall numbers (those mysterious integers in the sbprolog compiler
source code) with their symbolic names in syscall.h.  Then I run the
prolog source code through the c-preprocessor resolving the symbolic
names with the actual numbers.  (in retrospect, I probably should have
wrapped each in a conditional-compile to test whether the syscall
exists...)

I mailed the changes to Dr. Saumya Debray and I suspect they'll appear
in the next version (if they haven't already appeared).


>SB Prolog itself doesn't need 'syscall' in its full generality.
>All it needs to do is to map the numbers that are defined *in the SB Prolog
>manual itself* to the related system calls (some of which may well _not_ be
>system calls in some version of UNIX).  If that were done, it would be
>_much_ easier for other people to port SB Prolog in the future.
>
>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.  Since there
are a lot of system calls, using up a builtin for each would quickly
reach this limit.  The trick with using syscall is that only one
builtin is required, since the particular system utility needed is
encoded as an integer argument to syscall.  -- It may not be pretty,
but at least using syscall.h should make it a bit more portable.

-- 
Johnny Martin          (martin@umn-cs.cs.umn.edu)
Dept. Comp. Sci., 4-192 EE/CS, University of Minnesota, Minneapolis MN 55455
--