dave@csis.dit.csiro.au (David Campbell) (06/16/91)
G'day! I have seen postings in this group about a possible Amiga version of Eiffel (which is a recent object-oriented language & very nice to use). There is a new strongly typed object-oriented language being developed at the International Computer Science Institute at Berkeley. This new language is called Sather. Sather is a variant of Eiffel, syntactically very similar but simplified and optimized. They claim that Sather has performance 4 to 50 times that of Eiffel. The good thing about Sather is that its in the public domain. Full source for a Sparc beta version is available from icsi-ftp.berkeley.edu in directory pub/sather. Sather (like Eiffel) compiles to C and thus should be fairly portable. The run-time-system should be the most difficult part to port to the Amiga. The Sather compiler itself is written in Sather, thus source in C (generated from Sather) is included. Documentation (.ps) is also available from the ftp site. I'm interested in porting but if somebody wants to take charge of any serious attempt, do so. I think we can give up hope of compiling anything serious with Lattice C, I might try using GCC or compiling it on a Sun-3 and using the SOBJA program (from the Amiga GCC port) which converts Sun-3 object code to Amiga object code. -- Dave Campbell -- dave@csis.dit.csiro.au -- dave campbell
mueller@schaefer.math.wisc.edu (Carl Mueller) (06/16/91)
In article <1991Jun16.063222.1304@csis.dit.csiro.au> dave@csis.dit.csiro.au (David Campbell) writes: >G'day! > >I think we can give up hope of compiling anything serious with Lattice C, > Wait a second ... why do you say this? I have Lattice C (SAS/C) version 5.10 and haven't had any troubles compiling stuff. However, I am not really a programmer ... I'm working on my PhD in mathematics, so I'm not really in any position to judge a compiler. I would like to know what the limitations are that you see in SAS/C (Lattice C) for the AMIGA (if for no other reason than to know what I can expect my compiler to do [or not do]). Thanks. >-- Dave Campbell >-- dave@csis.dit.csiro.au Carl Mueller (mueller@math.wisc.edu)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (06/17/91)
In article <1991Jun16.145750.14475@schaefer.math.wisc.edu> mueller@schaefer.math.wisc.edu (Carl Mueller) writes: In article <1991Jun16.063222.1304@csis.dit.csiro.au> dave@csis.dit.csiro.au (David Campbell) writes: >G'day! > >I think we can give up hope of compiling anything serious with Lattice C, > Wait a second ... why do you say this? I have Lattice C (SAS/C) version 5.10 and haven't had any troubles compiling stuff. Well, if he only looks at GNU software, which is generally written as if memory were an infinite resource (among other problems), then I can see what would cause him to say that. I haven't had any real problems with it, and I _have_ compiled "serious" software with it. RCS (both of them) didn't create any serious problems. The byte code emulator for OAKLISP (a complete OO LISP System) works just fine, and I've got a disk ready to go to Fred Fish. The support library and REPL loop for Scheme->C (DEC's Scheme interpreter/compiler system) compiles with no problems, but I'm still chasing out the Unixisms. Having looked over the Sather source code (and rejecting it as a worthwhile thing to port), I don't think it would create any serious problems for the compiler. That Sather garbage collects the C stack in a rather ugly manner might cause problems. But that won't cause any more problems with SAS/C than it does with GNU. However, there are some good reasons for using GNU C for a Sather port.Mostly, Sather is liable to have been made to work with GNU C on Unix, so a lot of minor stuff will have been take care of. That you can't use GNU C on small machines isn't a real problem here - if your machine isn't big enough to run GNU C, then any non-trivial Sather application probably is probably going to have problems. <mike -- Love and affection, Mike Meyer Of the corporate kind. mwm@pa.dec.com It's just belly to belly, decwrl!mwm Never eye to eye.
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (06/17/91)
dave@csis.dit.csiro.au (David Campbell) writes: >G'day! >I have seen postings in this group about a possible Amiga version of Eiffel >(which is a recent object-oriented language & very nice to use). There will be an Amiga Eiffel. It is in the beta testing stage now. >There is a new strongly typed object-oriented language being developed >at the International Computer Science Institute at Berkeley. This new >language is called Sather. Sather is a variant of Eiffel, syntactically >very similar but simplified and optimized. They claim that Sather has >performance 4 to 50 times that of Eiffel. >The good thing about Sather is that its in the public domain. Full source >for a Sparc beta version is available from icsi-ftp.berkeley.edu in directory >pub/sather. Sather (like Eiffel) compiles to C and thus should be fairly >portable. The run-time-system should be the most difficult part to port to >the Amiga. The Sather compiler itself is written in Sather, thus source in C >(generated from Sather) is included. There are some problems that I have with Sather. First of all it is not a pure sub-set of Eiffel. There are differences in the syntax such as with arrays and genericity. All assertions use the keyword "assert" instead of Eiffel's keywords. And there are other keyword changes. Also, I have heard that the compiler isn't very type-safe. Personally, I feel that could have been a purer subset of Eiffel and still met its objectives. >Documentation (.ps) is also available from the ftp site. >I'm interested in porting but if somebody wants to take charge of any >serious attempt, do so. Go for it. I was tempted to try it myself. But I am too busy getting the Eiffel version finished. >I think we can give up hope of compiling anything serious with Lattice C, >I might try using GCC or compiling it on a Sun-3 and using the SOBJA program >(from the Amiga GCC port) which converts Sun-3 object code to Amiga object >code. You will save yourselves a lot of time by going with gcc or Matt's DICE. Sadly IMOO Lattice/SAS C with human coders in mind and not as intermediate object coders. SAS and Aztec can not handle calls to other functions greater than 32K in the same object file! Also beware of the limitations on SAS's macros. Also watch out for SAS's scanf() most un-UNIX like. >-- Dave Campbell >-- dave@csis.dit.csiro.au >-- >dave campbell Tal Lancaster
peter@sugar.hackercorp.com (Peter da Silva) (06/18/91)
In article <1991Jun17.161534.323@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: > There are some problems that I have with Sather. First of all it is not a > pure sub-set of Eiffel. Ack. The Turbo Pascal syndrome strikes again. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/20/91)
In article <1991Jun16.063222.1304@csis.dit.csiro.au> dave@csis.dit.csiro.au (David Campbell) writes: >G'day! > >I think we can give up hope of compiling anything serious with Lattice C, I've compiled the entire X distribution with the Lattice C compiler, is that "serious" ? -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/20/91)
In article <1991Jun17.161534.323@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >You will save yourselves a lot of time by going with gcc or Matt's DICE. >Sadly IMOO Lattice/SAS C with human coders in mind and not as intermediate >object coders. SAS and Aztec can not handle calls to other functions >greater than 32K in the same object file! Also beware of the limitations >on SAS's macros. Also watch out for SAS's scanf() most un-UNIX like. You could save yourself a lot of time by reading the documentation. The Lattice compiler will certainly call other functions more then 32K away, you just have to tell it that you don't want the short addressing mode enabled. (which it is by default because another set of programmers kept bitching about how big the code generated by the Lattice compiler was because they didn't know you could turn _on_ short addressing, either way, people who read the documentation don't seem to run into this stuff) Also you should read the section on large macros, which describes the limits and why you might want to use lc1b rather than lc1 if you have large macros, and last but not least, if you normally programmed on a SystemV UNIX machine you would not have been suprised at all by the behaviour of scanf in the Lattice library. It is more accurate to say that the Lattice scanf is most un-BSD like. -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"