[comp.lang.prolog] new SB-prolog diffs for DG

newton@smoggy.gg.caltech.edu (Mike Newton) (08/31/90)

Hi --

These patches (should) allow SB-Prolog to run on m88k machines, are have
been tested on the DG AViiON series.  These pathches leave the system in
a state that it should compile on all machines that it previously worked.
To get the system to work on a m88k BCS compliant machine, edit the file
sim/builtin/Makefile to include m88-syscall.s (see comments in file).

Notes : 
  [] the first patch below creates a new file (sim/builtin/m88k-syscall.s)

  [] these patches should also enable gcc usage on other machines.
	in particular, add you favorite opt.s to sim/Makefile and 
	sim/builtin/Makefile, and CC = gcc to sim/builtin/Makefile .

  [] these patches are relative to the version of SB-Prolog that is dated
	roughly Aug 24, 1990.

  [] the speed on an 16.7 MHz AViiON as measurd by nrev = 82+KLips.

  [] the latest patches reside on csvax.cs.caltech.edu::~ftp/pub/M88K

Enjoy, 
- mike newton
(newton@vlsi.caltech.edu)



*** sim/builtin/O.m88k-syscall.s	Mon Aug 27 11:13:43 1990
--- sim/builtin/m88k-syscall.s		Mon Aug 27 10:49:05 1990
***************
*** 0 ****
--- 1,43 ----
+ ;;; file created 3/30/1990 by Mike Newton
+ ;;; Copyright March 1990 by Mike Newton (newton@vlsi.caltech.edu)
+ 
+ ;;; This file may be freely distributed as long as it is not for profit.
+ 
+ ;;; This is distributed WITHOUT warranty or support of any kind.
+ ;;; Use at your own risk.
+ 
+ ;;; SB-prolog uses the bad-mannered habit of issuing Unix OS calls directly
+ ;;; by number.  This little routine will take these and massage them into 
+ ;;; what the 88k BCS OS's want.
+ 
+ ;;; WARNING -- WILL NOT WORK ON DOUBLES OR PASSED STRUCTS!!!!!
+ ;;; (shouldnt matter -- no one passes these to a kernel!)
+ 
+ 	file	"m88k-syscall.s"
+ 	ident	"@(#) m88k-syscall.s -- Copyright, 1990, Michael O. Newton"
+ 
+ 	text
+ 
+ 	global	_syscall
+ 
+ _syscall :
+ 	; need 2-->9, 9-->8, 8-->7, 7-->6, ..., 4-->3, 3-->2
+ 
+ 	or	r10,r9, r0		; OCS says i can put CC's here
+ 
+ 	or	r9, r2, r0		; get the syscall # into r9
+ 
+ 	or	r2, r3, r0		; get the first arg into r2
+ 	or	r3, r4, r0		; ....... 2nd   ........ r3
+ 	or      r4, r5, r0
+ 	or	r5, r6, r0
+ 	or	r6, r7, r0
+ 	or	r7, r8, r0		; ....... 6th   ........ r7
+ 
+ 	or	r8, r10, r0		; r8 is the last valid param reg
+ 
+         tb0	0, r0, 0x1c2		; issue Unix OS call
+ 
+ 	bsr	___cerror		; unix returns here on fail
+ 
+         jmp	r1			; and here on success
*** sim/builtin/O.Makefile	Mon Aug 27 11:07:39 1990
--- sim/builtin/Makefile	Mon Aug 27 10:53:53 1990
***************
*** 25,31 ****
  CFLAGS = -c -g
  OBJ1   = arith.o buffer.o builtin.o compare.o file.o init_branch.o meta.o
  OBJ2   = name.o other.o saverest.o structure.o substuff.o time.o tio.o token.o stlookup.o
! OBJS   = $(OBJ1) $(OBJ2)
  HS     = builtin.h ../aux.h ../sim.h
  
  builtin : $(OBJS) 
--- 25,34 ----
  CFLAGS = -c -g
  OBJ1   = arith.o buffer.o builtin.o compare.o file.o init_branch.o meta.o
  OBJ2   = name.o other.o saverest.o structure.o substuff.o time.o tio.o token.o stlookup.o
! # Hacked next line to get a syscall() that works on 88k machines -- Mike Newton
! OBJSYS = 
! #OBJSYS = m88k-syscall.o
! OBJS   = $(OBJ1) $(OBJ2) $(OBJSYS)
  HS     = builtin.h ../aux.h ../sim.h
  
  builtin : $(OBJS) 
***************
*** 34,67 ****
  	rm $(OBJS)
  
  arith.o : arith.c $(HS)
! 	cc $(CFLAGS) arith.c
  buffer.o : buffer.c $(HS)
! 	cc $(CFLAGS) buffer.c
  builtin.o : builtin.c $(HS) 
! 	cc $(CFLAGS) builtin.c
  compare.o : compare.c $(HS)
! 	cc $(CFLAGS) compare.c
  file.o  : file.c $(HS)
! 	cc $(CFLAGS) file.c
  init_branch.o : init_branch.c $(HS) 
! 	cc $(CFLAGS) init_branch.c
  meta.o  : meta.c $(HS)
! 	cc $(CFLAGS) meta.c
  name.o  : name.c $(HS)
! 	cc $(CFLAGS) name.c
  other.o : other.c $(HS)
! 	cc $(CFLAGS) other.c
  saverest.o : saverest.c ../sim.h ../aux.h 
! 	cc $(CFLAGS) saverest.c
  structure.o : structure.c $(HS)
! 	cc $(CFLAGS) structure.c
  substuff.o : substuff.c ../sim.h
! 	cc $(CFLAGS) substuff.c
  time.o  : time.c $(HS)
! 	cc $(CFLAGS) time.c
  tio.o   : tio.c $(HS)
! 	cc $(CFLAGS) tio.c
  token.o : token.c $(HS)
! 	cc $(CFLAGS) token.c
  stlookup.o: $(HS) stlookup.c
! 	cc $(CFLAGS) stlookup.c
--- 37,70 ----
  	rm $(OBJS)
  
  arith.o : arith.c $(HS)
! 	$(CC) $(CFLAGS) arith.c
  buffer.o : buffer.c $(HS)
! 	$(CC) $(CFLAGS) buffer.c
  builtin.o : builtin.c $(HS) 
! 	$(CC) $(CFLAGS) builtin.c
  compare.o : compare.c $(HS)
! 	$(CC) $(CFLAGS) compare.c
  file.o  : file.c $(HS)
! 	$(CC) $(CFLAGS) file.c
  init_branch.o : init_branch.c $(HS) 
! 	$(CC) $(CFLAGS) init_branch.c
  meta.o  : meta.c $(HS)
! 	$(CC) $(CFLAGS) meta.c
  name.o  : name.c $(HS)
! 	$(CC) $(CFLAGS) name.c
  other.o : other.c $(HS)
! 	$(CC) $(CFLAGS) other.c
  saverest.o : saverest.c ../sim.h ../aux.h 
! 	$(CC) $(CFLAGS) saverest.c
  structure.o : structure.c $(HS)
! 	$(CC) $(CFLAGS) structure.c
  substuff.o : substuff.c ../sim.h
! 	$(CC) $(CFLAGS) substuff.c
  time.o  : time.c $(HS)
! 	$(CC) $(CFLAGS) time.c
  tio.o   : tio.c $(HS)
! 	$(CC) $(CFLAGS) tio.c
  token.o : token.c $(HS)
! 	$(CC) $(CFLAGS) token.c
  stlookup.o: $(HS) stlookup.c
! 	$(CC) $(CFLAGS) stlookup.c
*** sim/builtin/O.other.c	Wed Aug 15 10:25:54 1990
--- sim/builtin/other.c		Mon Aug 27 10:57:43 1990
***************
*** 27,33 ****
--- 27,36 ----
  #include  <errno.h>
  #include <ctype.h>
  #include  <sys/types.h>
+ 
+ #ifndef m88k
  #include <sys/syscall.h>
+ #endif /* m88k */
  
  extern float    floatval();
  extern LONG_PTR insert();
*** sim/O.loader.c	Thu Apr 12 15:14:00 1990
--- sim/loader.c	Mon Aug 27 11:00:00 1990
***************
*** 51,57 ****
  static FILE *fp;
  static BYTE perm = PERM;
  
! extern fread();
  extern LONG_PTR reloc_addr();        /* actually it is defined below */
  
  /****************************************************************************/
--- 51,59 ----
  static FILE *fp;
  static BYTE perm = PERM;
  
! #ifndef __GNUC__
! extern fread();		/* this can be in the way on sysV or... -- MON */
! #endif /* __GNUC__ */
  extern LONG_PTR reloc_addr();        /* actually it is defined below */
  
  /****************************************************************************/

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (08/31/90)

In article <newton.652072040@smoggy>, 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.

martin@cs.umn.edu (Johnny Martin) (09/02/90)

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

newton@smoggy.gg.caltech.edu (Mike Newton) (09/02/90)

Agreed that the elimination of syscall would be nice, and that there are
problems doing it.  However, the new versions only use syscall for the socket
code.  This implies that 'access', which used to be done through syscall no
longer need it.  Thus, as long as you are not using sockets, porting SBprolog
can be done by adding the following line in any .c file:

	syscall() { fprintf(stderr,"\nsyscall called -- error\n"); }

(or some such).

Now if it only had a real GC'er!

- mike

ps: explanation of the last comment : after years maintaining a
version of C-Prolog, which we used to write a 370 Prolog compiler (not
available -- we dont have a 370 anymore) that obtained about 1M lip,
and lately using SB-prolog, i've come to believe that no Prolog is
complete until it has a GC'er.  

When our prolog had a GC'er added, it could suddenly compile itself,
and be used for other 'big' or 'real' jobs, making it 'more useful'
than C-Prolog and SB-prolog even thought it used 24 bit (16M)
addressing.  Before that, even though it was very fast, ours was not as
'useful', because, though C-Prolog and SB-prolog also could not GC, they
had a much larger address space.

(I've been looking into getting SICStus just for the GC'er, but as my advisor
is broke, i'd have to pay for it myself!)

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/11/90)

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.