🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #4836

Re: Laser C bugs

#4836
From: Darek Mihocka
Date: Sat, 14 Oct 1989 01:46
42 lines
3118 bytes
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.
------------------------------------------------------------------------------
Technical Details
Message-ID: <8044@microsoft.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!microsoft!w-darekm

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!microsoft!w-darekm
From: w-darekm@microsoft.UUCP (Darek Mihocka)
Newsgroups: comp.sys.atari.st
Subject: Re: Laser C bugs
Message-ID: <8044@microsoft.UUCP>
Date: 14 Oct 89 01:46:17 GMT
Reply-To: w-darekm@microsoft.UUCP (Darek Mihocka)
Organization: Microsoft Corp., Redmond WA
Lines: 42