sandersr@ecn-pc.UUCP (Robert C Sanders) (07/18/86)
[nibbles and bits...] I am very partial to the Computer Innovations C86 compiler, but I also like the Microsoft C compiler. The MS compiler is slower, and not as UNIX-like. Both libraries are interchanable -- at least in format. In other words, libraries in MS OBJ format are accepted and used by both compilers -- intended for the PC/MS DOS linker. Aztec C and Latice C are less friendly, and require work to port programs to/from them; CII's C and MS C easily port programs with UNIX (not requiring the system library), and are close (if not) to the new ANSI standard C going through. Third- party libraries are also compatible with CII C86 and MS C. - bob -- Continuing Engineering Education Telecommunications Purdue University ...!ihnp4!pur-ee!pc-ecn!sandersr Let's make like a BSD process, and go FORK-OFF !! -- bob (and "make" a few children while we're at it ...)
nather@ut-sally.UUCP (07/20/86)
In article <583@ecn-pc.UUCP>, sandersr@ecn-pc.UUCP (Robert C Sanders) writes: > I am very partial to the Computer Innovations C86 compiler, but I also > like the Microsoft C compiler. The MS compiler is slower, [ ... ] Not in my experience. I compiled the same (small model) program on three compilers, keeping track of time and code sizes. Here is the summary: ------------------------------------------------------------------------- The "ls.c" program was compiled using the CI-C86 compiler v 2.10 (cxls.exe), the DeSmet compiler v 2.3 (dxls.exe) and the Microsoft C compiler v 3.0 (mxls.exe). The Microsoft compiler had slightly more source code than the other two; an #ifdef added a few extra lines of code to speed up screen printing. Here are the compile times, using RAMdisk for all of the CIC and DeSmet compilers, and temp storage for Microsoft, which is too big to fit in RAMdisk. Source files were read from hard disk. Compile times: Ratio cxls.exe 3:37 (217 s) 5.1 dxls.exe 0:42 ( 42 s) 1.0 mxls.exe 2:48 (168 s) 4.0 Here are the resulting file sizes: d:/work/?xls.exe --w 15205 30 Jan 8:28p cxls.exe --w 17920 30 Jan 5:02p dxls.exe --w 12816 30 Jan 8:33p mxls.exe Execution times were measured for the command "xls -l d:/bin" which printed a complete screenful of data; the executable files were in RAMdisk to minimize loading time. Output was to screen, and into a file (in RAMdisk). Execution times: To Screen To file Ratios cxls.exe 6.5 s 3.0 s 1.6 1.6 dxls.exe 5.0 s 6.5 s 1.2 3.4 mxls.exe 4.1 s 1.9 s 1.0 1.0 Summary: DeSmet compiles 4 times faster than Microsoft, 5 times faster than CIC. Microsoft generates the smallest code with the fastest execution. CI-C86 has nothing outstanding to recommend it. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
adamsd@NOSC.ARPA (07/21/86)
FYI, our section at JPL (DSN Data Systems) has adopted the DeSmet compiler for any C programming that needs to be done (none as yet) after similar testing. Apparently, their main concern is development (read: compile & go) time.
toddo@uhmanoa.UUCP (Todd Ogasawara) (07/22/86)
Microsoft just sent me the Microsoft C Version 4.0 upgrade notice. Since
it will be "4 to 6 weeks" before I receive the upgrade (according to the
Microsoft order form), could someone please post a review of the new
window oriented symbolic debugger? There was also a hint in the upgrade
brochure that MS-DOS MAKE has been enhanced. Does anyone know what the
enhancements are? thanks...todd
--
Todd Ogasawara, University of Hawaii, Dept. of Psychology
UUCP: {ihnp4,dual,vortex}!islenet!
\
ihnp4!__\__ uhmanoa!toddo
/
{backbone}!sdcsvax!noscvax!humu!/
/
clyde/
ARPA: OGASAWARAT%HAW.SDSCNET@LLL-MFE.ARPA
** I used to be: ogasawar@nosc.ARPA & ogasawar@noscvax.UUCPalsup@bnrmtv.UUCP (Jim Alsup) (07/24/86)
> FYI, our section at JPL (DSN Data Systems) has adopted the DeSmet compiler for > any C programming that needs to be done (none as yet) after similar testing. > Apparently, their main concern is development (read: compile & go) time. I agree, I use to use DeSmet C for all my development. I now use DataLight's C, it's even faster for what's important (compile time). The end product can then be compiled in the best code (spell that runs fastest) producing compiler. Metaware's C ranks at top of the list for this purpose. I use still another compiler for porting large amounts of code from some other machine. MS C seems to be best at this job. Cheers, Jim Alsup
wolf@galbp.UUCP (Wolf) (07/29/86)
I've followed this discussion with interest, but was wondering
why CI86 (Computer Inovations (?)) never made it in any of the
survey articles. I've had limited experience with it and have had no
problems with it, whatsoever. In other surveys (e.g., Byte) it was always
in the top 3. Have I missed something?
--
Wolf Herda
Harris/Lanier
Computer R&D
{akgua,akgub,gatech}!galbp!wolfoleg@electra.cs.ucla.edu (Oleg "Kill the bastards" Kiselev) (08/06/86)
In article <419@galbp.UUCP> wolf@galbp.UUCP (Wolf) writes: >why CI86 (Computer Inovations (?)) never made it in any of the >survey articles. I've had limited experience with it and have had no >problems with it, whatsoever. In other surveys (e.g., Byte) it was always >in the top 3. Have I missed something? CI86 is neither very fast nor does it produce very good code. The biggie is the number of bugs in implementation of large memory model float, double and struct handling. CI86 (the release we had used a year ago) manages to mess up the addressing. CI86 is comfortable to use tho', and is fine (as far as we found!) for <64K stuff. -- "... having someone special for dinner?" Oleg Kiselev _Cannibal Girls_ oleg%OACVAX.BITNET oleg@LOCUS.UCLA.EDU