Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!ogicse!emory!rsiatl!jgd From: jgd@rsiatl.UUCP (John G. DeArmond) Newsgroups: comp.unix.i386 Subject: Re: LPI C review Message-ID: <3687@rsiatl.UUCP> Date: 24 Aug 90 02:04:47 GMT References: Distribution: comp Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and gun works facility) Lines: 33 eric@mks.mks.com (Eric Gisin) writes: >The cpu and real times of "lpicc -O" are twice that of "cc -O". >The object file text sizes are 20% larger for LPI C. >When compiling with -g, the times are four times that of "cc". >And with -g, the text segments are twice as large. >They add lots of "nop"s for unknown reason (its not alignment), >and seem to put debugging information in the text segment. >The LPI .o files are minimally COFF compatible; >they will link with "ld" but have no COFF debugging information. Pretty much confirms my (rather brief) first impressions of this stuff. The very first impression I got from reading the documentation (gasp!) was that what I had on my hands was a COBOL compiler with the OBOL dropped (grudgingly). That plus the fact that it appeared that they reinvented the wheel at every opportunity make me do an early disk purge. Hmm, seems to me that if ISC would just supply the GNU stuff as their "enhanced" compiler and concentrate their efforts (and our money) on things like fixing the ASY drivers and fixing (or completing) sysadm and fixing mkpart and make the floppy driver catch more than one sector per revolution and so on and so forth, we'd all be lightyears ahead. Anyway, glad to see I'm not the only one underwhelmed by LPI. John -- John De Armond, WD4OQC | We can no more blame our loss of freedom on congress Radiation Systems, Inc. | than we can prostitution on pimps. Both simply Atlanta, Ga | provide broker services for their customers. {emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA**