🚀 go-pugleaf

In article <28532@usc>, charles@rayleigh.usc.edu (Charles A. Njinda) writes:
> I am interested in getting Franz Lisp for Sun Sparc Stations running Sun
> OS4.1. Could some kind soul please tell me where I can get a copy either
> by ftp or some other means?
> 
> We have just upgraded our sun system to sparc stations and our previous
> version for sun 3/60 can not be used. We do not have the source codes !!
> 
> Please email
>       charles@poisson.usc.edu
> 
>  or
>      mb@poisson.usc.edu
> 
> Regards
> 
> Charles

As far as anyone knows the Franz Lisp system has not been ported to
the Sparc. Porting the C code of the interpreter may not be too difficult,
and dealing with the bit of assembler in the bignum package may not be
too bad, (most of it could be replaced by C code), but the COMPILER
may be difficult.

The Franz compiler originally generated VAX assembler, and a 68000 code
generator was added at Berkley in the early 1980's. There have been ports
to other processors, such as the NS32000 (which is similar to 68xxx and VAX).

The SPARC would be different than these. Perhaps it would not be too big
a job to generate straightforward code, since the usage of the VAX and 68xxx
instructures sets was not at all extensive in the original compiler.

As far as getting the source codes. Try Anonymous FTP to BU.EDU
and looking in the language or lisp subdirectories.

Oh. The other changes needed would be to the FASLOADER, to account for
the difference between BSD and "COMMON" (SYSV) object format.

-gjc

As one of the people who worked on the Sun3 port of Franz I'd say the
attack I would take at this point would be looking at how hard it
would be to get franz (liszt actually) to generate C code. At that
point it would port to all sorts of systems more quickly. Hand coded C
subrs are pretty well defined if you look at the code, and that's what
you want to generate in liszt.

As gjc mentioned, you still have to do hand-to-hand battle with the
real-time object loader for every port, no matter how portable you
make everything else. On some machines it's painful to do this, or at
least takes a very stubborn attitude to get it finished. Of course, on
some systems it's not very hard at all (COFF tends to be a pain, BSD
systems tend to be pretty straightforward, particularly if the loader
supports the incremental loader options, -A and -T.)
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

In article <BZS.90Dec21201025@world.std.com>, bzs@world.std.com (Barry Shein) writes:
> As one of the people who worked on the Sun3 port of Franz I'd say the
> attack I would take at this point would be looking at how hard it
> would be to get franz (liszt actually) to generate C code.
I recall RJF on the 8'th floor (around 1978) telling us Mathlab
types about Franz and the first Franz compiler attempt, which did
indeed produce C code.

In article <BZS.90Dec21201025@world.std.com> bzs@world.std.com (Barry Shein) writes:
>
>As one of the people who worked on the Sun3 port of Franz I'd say the
>attack I would take at this point would be looking at how hard it
>would be to get franz (liszt actually) to generate C code. At that
>point it would port to all sorts of systems more quickly. Hand coded C
>subrs are pretty well defined if you look at the code, and that's what
>you want to generate in liszt.

I have a Liszt that generates C, but I haven't wanted to do all the
other things (loader, losing C code in Franz, etc) to make Franz work
on the SPARC.  The Liszt works on Sun 3, VAX, and (the original
reason) on a Perq running PNX, so it is likely to be sufficiently
portable.

So if anyone is seriously interested in doing a SPARC port, I may
be able to help.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton