w-darekm@microsoft.UUCP (Darek Mihocka) (10/14/89)
Someone sent me mail about Laser C which I could not send back, so I am posting this here for anyone else that's interested. The code generation bugs are mainly in the inline assembler. For example, the MOVEP instruction generates bad code. dc.l and dc.b generate bad code (only dc.w works fine), branch statements sometimes miss their target by a few bytes, etc. It's just an all round bad assembler. The C code generation has some problems when you get pointers to structures containing pointers, etc. What also irritates me is that if you have a string constant and you forget to put in the closing quotation marks, it crashes. All of these bugs have been present since Megamax C, I keep reporting them, and they keep ignoring them or telling me they're fixed. That's pissing me off to no end, because otherwise I like the package a lot. The disk cache tends to mess up when you are low on RAM and compiling a large program (i.e. more than one module or more than a "hello world" skeleton). The are more files than the disk cache can handle, and so it starts to thrash very badly. The cache is a file cache, not a sector cache, therefor if you are dealing with large files, say the LIBC.A library, it has to flush out a large number of files before it can load the big file. If your program has to deal with a large data file, such as converting a 24-bit RGB image to a Degas picture, which I used to do a lot, you have to exit the Laser C shell and run the program, then re-enter it to make edits. Trying to run such a program from within the shell results in a major slowdown in disk speed. A file that would normally take a second to load from the hard drive can take half a minute. I find that completely unacceptable. Sure the cache is great if you're compiling off floppy, but you're not going to develop a large project on floppy. The cache should be smart enough to figure out that any drive letter C: or higher should not be cached. - Darek ------------------------------------------------------------------------------ Darek Mihocka ST Xformer II CIS: (out of order) Box 2624, Station B Quick Utilities GEnie: DAREKM Kitchener, Ontario MegaBlit SSG SPX DELPHI: DAREKM N2H 6N2 Shareware, not Vaporware BIX: darekm Canada OS/2 > GEM^2 CheapNet: ...!uw-beaver!microsoft!w-darekm (519)-747-0386 A mind is a terrible thing to waste, so JUST SAY NO TO TOS. Opinions expressed are my own and not those of anyone not named Darek Mihocka. ------------------------------------------------------------------------------
horsch@grads.cs.ubc.ca (Michael Horsch) (10/14/89)
In article <8044@microsoft.UUCP> w-darekm@microsoft.UUCP (Darek Mihocka) writes: [some gripes about Laser C... The ones I am addressing are not edited out (how's that for being contrapositive!)] > The C code generation has some problems when you get >pointers to structures containing pointers, etc. I have never had this one, and I've been messing around a lot with objects, and structures which contain pointers to objects, and linked lists of trees whose nodes point to objects, and... > What also irritates >me is that if you have a string constant and you forget to put in the >closing quotation marks, it crashes. Not this either. I always forget to close qoutes. Sometimes I forget the difference between " and '. I only get compiler errors. > All of these bugs have been present >since Megamax C, I keep reporting them, and they keep ignoring them or >telling me they're fixed. That's pissing me off to no end, because otherwise >I like the package a lot. Keep reporting them. I would too, if I found any. But mostly I find my own bugs. No implication implied. > >The disk cache tends to mess up when you are low on RAM and compiling a >large program (i.e. more than one module or more than a "hello world" >skeleton). I assume the parenthetical remark to be slightly sarcastic, but your argument about low RAM behaviour makes sense to me (I have a Mega2, so this is never a problem). I agree with an earlier posting in which you suggested that the cache be optional. >Sure the cache is great if you're compiling off floppy, but you're not going >to develop a large project on floppy. Why not? The disk cache and RAM resident tools make this completely reasonable. A little painful at the start of a programming session (and after unrecoverable errors), for sure, but certainly not completely unthinkable. Especially for those (i.e. me) who (perhaps) misguidedly purchased a machine with more RAM instead of a hard disk. I am not a real C programmer, that is, I don't spend months working on real projects (in fact, I'm a Prolog hacker `by trade' :-) and my Mega2 is somewhat ignobly reduced to a real slow terminal for most of its use) so I consider one-floppy development adequate for my medium sized hacks ---but only with the cache, etc. > >- Darek Mike ("By trade?" --Well, it beats working for a living!) -- Michael C. Horsch Disclaimer: I'm not thinking for anyone else but horsch@cs.ubc.ca me; I'm having enough trouble as it is! Dept. of Computer Science University of British Columbia -- If you don't waste time with your friends, you're just wasting your time. --