Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!jarthur!nntp-server.caltech.edu!smoggy!newton From: newton@smoggy.gg.caltech.edu (Mike Newton) 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: Date: 1 Sep 90 20:50:55 GMT References: <3653@goanna.cs.rmit.oz.au> <1990Sep1.170632.13330@cs.umn.edu> Sender: news@laguna.ccsf.caltech.edu Organization: California Institute of Technology Lines: 30 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!)