Newsgroups: comp.realtime Path: utzoo!utgpu!cunews!bertrand!greg From: greg@organia.sce.carleton.ca (Greg Franks) Subject: Re: RSX -- one of the best? In-Reply-To: klaus@captain-crunch.ai.mit.edu's message of 6 Jun 91 00: 51:10 GMT Message-ID: Sender: news@cunews.carleton.ca Organization: /home/organia/greg/.organization References: <16302@life.ai.mit.edu> <16324@life.ai.mit.edu> Distribution: comp.realtime Date: Thu, 6 Jun 1991 14:51:49 GMT In article <16324@life.ai.mit.edu> klaus@captain-crunch.ai.mit.edu (Klaus B. Biggers) writes: >despite the hit on performance, because reliability was more important >than speed. We also found that the performance hit was not all that >bad anyway. If you know where its critical to check the range, you can just call a macro that checks it for you. And then you can take action depending on what the exact situation is. i.e. sometimes you may want to core dump, other times you may want to just print something. Good point. However, *people are lazy*, and they will not do things like "I better do a range check here". See the point about lint. > >Ansi C has not been in existance for all that long. Regrettably, lint >is not used. (Try running lint on some AT&T System V.3 source code >sometime. :-(). I thought this was for code you wrote? If you want to do type checking as you mentioned and what I was talking about, it is a simple matter to prototype the system function calls to assure that you don't get things like "pointer surprise". You don't need to recompile (or lint) the system code to assure that the types you pass in are correct. I have found that most often, you can find someone that has already done the prototyping for you (or you can use the P.D. program "protoize" which does it for you). > If it isn't built into the compiler, it will not be >used. hmmm, interesting comment.. maybe you need to hire some programmers that know theres more to writing code than "cc foo.c". Do your people use debuggers? profilers? I think that if you specify to the programmers that it must pass lint, they'll learn to use it. Again, people are lazy. I didn't do the hiring, but in a large project, you will get a large variation in the abilities of the people. You need not worry about the people who know how to use lint et al. You need to worry about those who don't (and there will be some). Your system is only going to be as good as the weakest person on the team. If your tools can make that person better (eg, type checking, lint built in etc), you will make your life easier. > > portability-- what't that? > data abstraction-- what't that? > > what did you use on RSX11?? fortran? > >I forgot about the RSX connection, it was a long time ago. To answer >your question, Macro-11. Portability, who cares. Data abstraction, >what's that? :-) > I stand corrected here.. now we're talking type checking and a great language for large multi-programmer projects. And just think.. it'll run on all those PDP's out there. :) David Parnas is having a grand time doing verification on the system actually. Fortuneately, you only need 256K to run a nuclear power station. Talk about S/W bloat though. One of the original power stations here in Ontario runs on an anchient IBM machine with a whopping 32 kwords of *CORE* (yes, the little magnetic donuts). Now they are up to 256K (no virtual memory either!). >Portability is often not an issue with real time systems because it is >expensive to change the hardware. I didn't mean just porting *my* code to new hardware. I meant being able to use the millions of lines of code already written to the hardware I'm already using. I port other peoples code to my platforms much more often than I port my code to other peoples platforms. For example, if I want to use a Kalman filter somewhere on my hardware, I don't need to write it, I only need to recompile it using someone else's code. Portability is *always* an issue. Why reinvent the wheel? Writing and testing software is VERY expensive. I would rather use everything I can find thats already been written and at most modify it to fit my needs. That way I can spend my time doing original work that hasn't already been done by someone else using existing code for the majority of the nuts and bolts kind of stuff. There are a lot of very sharp programmers out there that have written a lot of code. More than I and the rest of the programmers I work with could write. Therefore, I'd rather start where they left off rather than where they started. Also, if you write code that is portable, when you move on to a new project, with new hardware, a lot of the code is already written and you don't need to start from scratch... again... Now you are talking about reuse. Reuse was not an issue in the real-time systems that I have delt with although it probably should have been. Unfortunately, reuse is a problem in the real world (eg, the Not Invented Here Syndrome). For reuse in general, I would rather use a language where the interface can be defined adequately (perhaps C++??). Smalltalk is quite nice in this area. > And if you change the hardware, >almost everything else changes too because much of the code deals with >all of those fancy devices you have hooked up to the system. Wrong... not if you write the device dependent code as separate modules that get called by device independent higher level routines with generic interfaces. We've used many different devices hooked to many systems and are able to use the same high level software on all of them. If we start a new project or move to new hardware, all we need to rewrite is the lowest level software which directly deals with the hardware... but that requires some knowledge of data abstraction in order to effectively write the interface. Again, on the systems I worked on, changing hardware was a royal pain. Manufacturing would scream. Projects run over 10 year+ periods. > The >RSX-system was designed to run for 30 years after a 10 year >development period. The hardware chosen for the project was not the >newest or sexiest, but one that would probably still be available in >some form or another for the entire life span of the plant. > There is definitely something to be said for stability.. but if you'd written your code to be portable, you could replace the whole system in ten years with something higher performance and much cheaper. Ten years ago you couldn't do on a million dollar mainframe what you can do today on a twenty thousand dollar workstation... and if your code is portable, you have the option to use the new cheaper technology. C is not the only "portable language". It also can be quite non-portable. Try porting gnu-emacs to a 286 running UNIX. (Can gnu-emacs be ported to machine that cannot support calloc??? -- just asking, I'm curious). Recall the "all the world's a VAX syndrome. Replacing control systems with the "latest and greatest" is not often done. Why bother? Replacing means buying new hardware, which is often NOT cheaper than leaving the old stuff alone. (You would be amazed at the musem pieces running some of the power stations here in Ontario). >Don't get me wrong. I do like C. I use it all the time, but only on >software with small teams (< 5 people). But I get scared when I >consider the consequences of large design teams (> 50 developers) >using it as *the* development language, especially on hardware with >minimal or non-existant memory management support. There are a lot of large groups doing programming in C with little evidence of problems. X-windows is written in C and was written by *many* programmers, especially if you also consider all of the contrib stuff. Then there's the Free Software Foundation whose editor (gnuemacs) and c compiler (gcc) are IMHO the best around. gcc even lets you give the compiler command line options to flag warnings much like lint so lint actually is part of the compiler... just like you wanted. Funny, I have never heard anyone actually praise 'X' before :-) (eg: Hugh Redelmeier: "the average pointer statistically points to someplace in X"). Has anyone run a profiler on it??? (humour impaired, add :-)). GCC and GNU emacs are quite nice -- this posting comes to you courtesy of the latter. C is getting better w.r.t. prototyping (took them long enough), but it is still a structured assembler. C++ is better still. Why isn't lint built into *all* C compilers? Large projects can be done in C, but they an also be done in assembler. Type-safe languages just make the job *easier*, which is the whole point. > Fortran is no >better. (I like Concurrent Euclid myself -- real time programming >made easy! Who knows, I might even like Ada.) > I didn't think anybody liked ADA :) I'm not particularly crazy about it either actually. I guess the US DOD likes it though. Ada is also a 'portable' language. Maybe that's why they are using it. -- Greg Franks, (613) 788-2800 x5726 | "The reason that God was able to Systems Engineering, Carleton University, | create the world in seven days is Ottawa, Ontario, Canada K1S 5B6. | that he didn't have to worry about greg@sce.carleton.ca ...!cunews!sce!greg | the installed base" -- Enzo Torresi