Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!ai-lab!captain-crunch!klaus From: klaus@captain-crunch.ai.mit.edu (Klaus B. Biggers) Newsgroups: comp.realtime Subject: Re: RSX -- one of the best? Message-ID: <16324@life.ai.mit.edu> Date: 6 Jun 91 00:51:10 GMT References: <16302@life.ai.mit.edu> Sender: news@ai.mit.edu Distribution: comp.realtime Organization: MIT Artificial Intelligence Laboratory Lines: 156 In article greg@organia.sce.carleton.ca (Greg Franks) writes: >In article <16302@life.ai.mit.edu> klaus@captain-crunch.ai.mit.edu (Klaus B. Biggers) writes: > > In article greg@organia.sce.carleton.ca (Greg Franks) writes: > > > >The *lack* of a C compiler is often considered an advantage in the > >context of larger real-time systems (i.e., those with lots of people > >working on the same 8-megabyte program). Type checking -- what't > >that? :-). > >-- > > I think they call it ANSI C and prototyped functions... or there's lint > which will do your type checking. C has some really nice advantages.. > >C still doesn't do enumerations well. Arguments of values 1..10 are >still stuffed in integers or characters or whatever in C. The >compilers I used for real time switching systems put range checks in >strategic locations for enumerated types (Dialed digit '60' is out of >range 0-9: core dump). We never turned the range checking off, core dump?? ouch.. pretty drastic. >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. > >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. > > 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. :) >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... > 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. > 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. >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. > 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 :) > >-- >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 Ahh.. but if god had used a portable language, we'd have a faster and cheaper version by now. :) -klaus klaus@snowhite.ced.utah.edu _______________________________________________________________________________