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: <GREG.91Jun6095149@organia.sce.carleton.ca>
Sender: news@cunews.carleton.ca
Organization: /home/organia/greg/.organization
References: <GREG.91May24100015@organia.sce.carleton.ca> <16302@life.ai.mit.edu>
	<GREG.91Jun5150023@organia.sce.carleton.ca> <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  
