Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site weitek.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!spar!turtlevax!weitek!mahar From: mahar@weitek.UUCP (mahar) Newsgroups: net.arch Subject: Re: What I miss in micro-processors (fairly long) Message-ID: <282@weitek.UUCP> Date: Wed, 2-Oct-85 17:54:13 EDT Article-I.D.: weitek.282 Posted: Wed Oct 2 17:54:13 1985 Date-Received: Sat, 5-Oct-85 07:07:46 EDT References: <796@kuling.UUCP> <2580002@csd2.UUCP> <191@graffiti.UUCP> <276@watmum.UUCP> Organization: Weitek Corp. Sunnyvale Ca. Lines: 36 Summary: correctness vs speed I think there is no real harm in having range checking in a program. It is important that somthing reasonable be done when an error occurs. This is not always the case in commercial products. I was using a turn key cad station when I did somthing wrong. I don't remember exactly what but the system responded with: Range check error at line 143 in module intcore and returned to the operating system. This was a turn key system so I had no documentation on what the operating system was, its commands, or, more importantly, how to recover and save the five hours work that was lost. The only thing I could do was reboot the system and start over. If the system were properly designed this condition whould have been at most a little bothersom. Most programming dogma declares that a correct program that runs slow is better then an incorrect one that is fast. For the most part this makes sense. There are, however, cases where this is not so true. Suppose there is an application which has a few well know bugs. Would the user community prefer that version of the application over one that has fixed the bugs but run 100000 times slower? 2 times? Most the users I know would not switch if they could notice any performance loss. Another concern reguarding speed is real time applications. It is easy, and common, to imagine a program which will work without range checking and not work with. In many video applicatons, the program does not work if the screen can't be updated in a single frame of 1/60th of a second. If you miss by as much as a micro second your dead. Under those circumstances I would gladly sacrifice range checking. In other postings the idea of forceing a parity error on uninitialized ram locations was presented. This has, as far as I can tell, the property that uninitialized accesses are undistinguishable from parity errors. This can cause a problem. On this system, the majority of parity errors will uninitialized variables. What if you get a real parity error? As a program developer, my first guess whould be that this was an uninitialized variable. What I would not be able to do is reproduce the bug. This is the stuff that nightmares are made of. After a review of the code I whould not find anything wrong but I whould never be certain that this 'hidden bug' whouldn't crop up again. Brought to you by Super Global Mega Corp .com