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!"
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (06/22/91)
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) 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, >I've compiled the entire X distribution with the Lattice C compiler, is >that "serious" ? I believe the point is that neither SAS nor MANX can be considered "industrial strength" compilers. That is to say a compiler for all situations with minimal hassels. Chances are, I think people will have less trouble porting something if they use gcc or DICE. I still try to use SAS when I can (primarily for the source level debugger which neighter gcc or DICE have). But there are times when SAS just won't cut it and I have to use gcc. I have only run across 1 bug with gcc, which is a lot better than what I can say for SAS and MANX. >-- >--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!" Tal Lancaster
ben@epmooch.UUCP (Rev. Ben A. Mesander) (06/23/91)
In article <15547@exodus.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: [...] >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) SAS had some interesting bugs at one time regarding code generation in the presence of functions that generated >= 32K of object in a source file. The problems I was having with compiling GNU chess went away in the latest release, but some other people have reported problems with f2c output still causing SAS/C to generate incorrect branches in the presence of very large functions. >--Chuck McManis Sun Microsystems -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
wild@nessie.cs.id.ethz.ch (Markus Wild) (06/30/91)
In article <ben.3470@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: [.....] >file. The problems I was having with compiling GNU chess went away in >the latest release, but some other people have reported problems with >f2c output still causing SAS/C to generate incorrect branches in the >presence of very large functions. So why don't you just use gcc for those huge beasts? Gcc doesn't have such 16bit problems, it doesn't have problems with huge macros, so I can really see no reason why not to use it for such programs as gnu-chess, that won't use any amiga-special features (like __chip) or on the output of a fortran-converter. Depending on your personal preferences, you can run the output thru converters to generate either Manx object files or hunk format object files (for you BLINK users..), or you can use gnu-ld to directly generate load-files, completely avoiding the use of a certain monster called "official" linker;-)) For those without gcc, it can be obtained (the converters and gnu-ld too) from nic.funet.fi. -Markus -- Markus M. Wild - mwild@iiic.ethz.ch | wild@nessie.cs.id.ethz.ch
ben@epmooch.UUCP (Rev. Ben A. Mesander) (06/30/91)
In article <1991Jun29.232046.6932@bernina.ethz.ch> wild@nessie.cs.id.ethz.ch (Markus Wild) writes: >In article <ben.3470@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >[.....] >>file. The problems I was having with compiling GNU chess went away in >>the latest release, but some other people have reported problems with >>f2c output still causing SAS/C to generate incorrect branches in the >>presence of very large functions. > >So why don't you just use gcc for those huge beasts? Gcc doesn't have >such 16bit problems, it doesn't have problems with huge macros, so I >can really see no reason why not to use it for such programs as gnu-chess, Markus, I didn't do that, because at the time, GCC hadn't been ported to the Amiga. I have a copy of GCC on my hard drive now, which is what I most certainly use for such a project. GNU Chess was a bear to port with SAS/C. Just as an experiment, I once tried to compile the source that now works under SAS with GCC to see what sort of speed improvement I got in the code. Well, it no longer will compile with GCC, mainly due to problems with things like: spam(short foo, short bar) Which SAS is apparently sure to make sure that you cast everything passed to spam as shorts (even constants) (This actually was Lattice 5.05, I beleive) and GCC didn't like the things I had to do to fix that. Oh, and Lattice didn't like "short unsigned int", I had to switch that around to "unsigned short int". I thought that was sort of silly. I also had to expand some macros by hand, I think. SAS/C 5.10a is a big improvement over Lattice 5.05. -- | ben@epmooch.UUCP (Ben Mesander) |CNEWSMUSTDIECNEWSMUSTDIECNEWSM| | ben%servalan.UUCP@uokmax.ecn.uoknor.edu |USTDIECNEWSMUSTDIECNEWSMUSTDIE| | ...!chinet!servalan!epmooch!ben |CNEWSMUSTDIECNEWSMUSTDIECNEWSM|