Xref: utzoo comp.sys.m88k:299 comp.lang.prolog:3124 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!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.sys.m88k,comp.lang.prolog Subject: Re: new SB-prolog diffs for DG (& probably other m88k) machines Keywords: m88k prolog patches sb-prolog dei Message-ID: <3653@goanna.cs.rmit.oz.au> Date: 31 Aug 90 08:08:58 GMT References: Followup-To: comp.lang.prolog Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 26 In article , newton@smoggy.gg.caltech.edu (Mike Newton) writes: > These patches (should) allow SB-Prolog to run on m88k machines, are have > been tested on the DG AViiON series. > + file "m88k-syscall.s" > + ident "@(#) m88k-syscall.s -- Copyright, 1990, Michael O. Newton" 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. 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. -- You can lie with statistics ... but not to a statistician.