grunau_b@husc4.UUCP (02/20/87)
I have two simple compiler questions: (a) does anybody have any idea how many different object file formats there are for the ST? I know there's DRI (Alcyon), and that Lattice is compatible with it; what else is there and what compilers are capable of producing formats compatible with what? (b) about ANSI compatability -- are there any compilers out there that are fully ANSI-standard, or at least as much as Lattice or Microsoft C are for the IBM? Which compiler(s) have the most ANSI extensions? In particular, is Lattice fully extended (e.g. passable structures/arrays, fully-specified function declarations [with a typelist for the parameters], enum and void types, and concatenatable strings)? I also wonder, for anybody who cares to answer, whether there is anything about Lattice C that dis-recommends it other than the fact that it produces rather large code (closely related to its use of 32-bit values for all expressions, I assume). That is, is Lattice also buggy, or not as robust in its runtime library, etc. thanks, JJMG grunau@husc4.UUCP or --- !seismo----- \ --- !rutgers----- !husc6!husc4!grunau / --- !decvax!ihnp4 or For BITNET, I believe the hostname is "harvard".
john@viper.UUCP (02/21/87)
In article <1264@husc6.UUCP> grunau_b@husc4.UUCP (Justin J. M. Grunau) writes: > >I have two simple compiler questions: > ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, > > (b) about ANSI compatability -- are there any compilers out there that > are fully ANSI-standard, or at least as much as Lattice or > Microsoft C are for the IBM? Which compiler(s) have the most > ANSI extensions? In particular, is Lattice fully extended (e.g. > passable structures/arrays, fully-specified function declarations > [with a typelist for the parameters], enum and void types, and > concatenatable strings)? > ("Simple" eh? I'd hate to see what he's got in his "hard questions" list.) I hate to break this to you Justin, but there is no ANSI standard for C (yet). As soon as they (the standards group) get their act together and and the standard is published ask your question again and, -then- you might get an answer....
pes@bath63.UUCP (02/23/87)
I find Lattice C totally acceptable. It has a number of useful compile time options, including the ability to make either of the two major flavours of object module. Produces nice code, and quite fast *if* you remember to explicitly declare things that can be held in short's to be short. (My own opinion is that they got that one right, and that the rest of the world is out of step. Sloppily written programs are far less likely to blow up obscurely when you use a long for something that could have been short, than if you use a short for something that needs a long. I see it as a safety feature -- and I think (heavy opinion here) that anyone who considers himself or herself a 'top-class' programmer should be using full explicit declarations (i.e. short int or long int) and not relying on the defaults.) It comes with a very nice library including all the GEM/TOS/etc mappings, and additionally most if not all of the K&R Unix-like functions. And, it's got a floating point package which appears (haven't tested exhaustively) to be accurate -- which I understand is not true of some C's available. On the minus side, the library functions are not well documented, so you'll need something external for that. The editor is adequate but not great -- on the other hand, who buys compilers for the attached editor? And at present there's no nice debugger. Since they're right around the corner from me (MetaComCo UK, that is) I occasionally bug them about that one -- it's reached the status of a Real Soon Now project. Another potential weakness is that (at least at my rev) they don't supply the init file you'd have to link in if you're writing Desk Accessories -- I keep meaning to try to hack one up -- but they do (of course?) have the one you need for standard applications.
braner@batcomputer.UUCP (02/26/87)
[] If you want your programs to be portable, DON'T use 'short' directly. Your Lattice 'short' is 16 bits, while, for example, Megamax 'short' is 8! One solution is to use 'WORD' and "#define WORD short /* 16 bits */" at the top of your program (or in a standard include file). About floating point performance of the C compilers: most of them are TERRIBLE. Slow and buggy. This is my main problem in using the ST for scientific programming. The IEEE format is partly to blame (very badly suited for the 68000 architecture), but that's not the only problem. Inefficient code is the real culprit. (Trig functions written in C (!). Calls to a dispatcher, passing an op code, rather than directly to the appropriate routine. Unnecessary extra copying of data...) Absoft FORTRAN, for example, does FP an order of magnitude faster than Megamax C. Not to mention that Megamax log(x) yields garbage for negative x (instead of an error message) and HANGS upon log(0)... Alas, I HATE FORTRAN (for no rational reason :-). When will the C compiler vendors realize that some people are serious about using FP? I love C, but it is not for everything. THE COMPLETE FP PACKAGE _MUST_ BE WRITTEN IN HAND-OPTIMIZED ASSEMBLER LANGUAGE!!! - Moshe Braner