jasst3@cisunx.UUCP (Jeffrey A. Sullivan) (08/30/88)
If there's anything about LSC 3.0 of particular merit (or demerit), I'd like to hear about it for a possible magazine article I'm writing. Email me with the stuff and I'll summarize. All levels of comment (from non-user to mega-hacker) are appreciated. -- .......................................................................... Jeffrey Sullivan | University of Pittsburgh jas@cadre.dsl.pittsburgh.edu | Intelligent Systems Studies Program jasper@PittVMS.BITNET, jasst3@cisunx.UUCP | Graduate Student
bytebug@dhw68k.cts.com (Roger L. Long) (08/31/88)
In article <12121@cisunx.UUCP> jasst3@cisunx.UUCP (Jeffrey A. Sullivan) writes: >If there's anything about LSC 3.0 of particular merit (or demerit), I'd like >to hear about it for a possible magazine article I'm writing. My main gripes with Think-C are: it generates some of the worst code I've seen a compiler generate and it sure would be nice if I wasn't locked into using their editor (i.e. if the thing were modular enough that I could write my own "shell" and "editor" to look and feel the way that I want. -- Roger L. Long dhw68k!bytebug
fjo@ttrdf.UUCP (Frank Owen ) (09/02/88)
in article <11062@dhw68k.cts.com>, bytebug@dhw68k.cts.com (Roger L. Long) says: > > My main gripes with Think-C are: > > it generates some of the worst code I've seen a compiler generate Have you compared it with some of the other non-optimizing C compilers on the Mac?. I think it compares very favorably with any of them. In fact, I think the ONLY Mac C compiler that generates any better code is the MPW compiler. It is a true optimizing compiler, and generates pretty decent code. -- Frank Owen (fjo@ttrdf) 312-982-2182 AT&T Information Systems Computer Systems Division, 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ttrdf!fjo
jwhitnell@cup.portal.com (09/02/88)
Roger L. Long writes |My main gripes with Think-C are: | it generates some of the worst code I've seen a compiler generate You havn't looked at the output of too many compilers :-). The first version of the megamax compiler wins that award hands down. Take a look at the code it generated for switchs sometimes if you want a good laugh. The code generated by LSC is relativly clean and minimal. The problem is that it doesn't have either a peephole optimizer or a real optimizer to back it up. This leaves it with lots of code that could be eliminated. | | it sure would be nice if I wasn't locked into using their editor (i.e. | if the thing were modular enough that I could write my own "shell" | and "editor" to look and feel the way that I want. There is a lot of talk about a solution for this "problem" in LSC 4.0. Solutions that have been discussed in public include using C as a macro language (compile by the compiler), allowing new editors too replace the old in LSC and communicating via IAC with a 3rd party editor under MF. Which solution they will choose and when 4.0 will be avaiable is anybodies guess. -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell
atchison@hpindda.HP.COM (Lee Atchison) (09/08/88)
I'd also like to say that after working with LSC and the debugger for quite a while now (since it first came out), I am also impressed with it. I've uncovered several bizaare stack-overwrite problems in the debugger that would have taken me a long time without it (I don't have TMON, and Macsbug leaves a lot to be desired for this type of problem). It has saved me lots and lots of time. BTW, I'm writing a fairly-decent size application (2000-3000 lines of code, uses a 128k partition) and I'm writing it, USING THE DEBUGGER, on a standard 1MB MAC+!!!! No, its not quite as convient as I would like, as I have to boot without several of my very-useful INITs (the one that I really miss under this environment is QuickKeys), but it works! I still want to upgrade to 2M, but at least now I can wait awhile. -lee