kenw@skyler.arc.ab.ca (Ken Wallewein) (05/16/91)
Back when I worked with RSX, my impression was that it was one of the best real-time OSs available. It doesn't seem to have been mentioned here much lately. Would anybody mind filling me in on why? /kenw -- /kenw Ken Wallewein A L B E R T A kenw@noah.arc.ab.ca <-- replies (if mailed) here, please R E S E A R C H (403)297-2660 C O U N C I L
murphy@corsair.uucp (Bill Murphy) (05/16/91)
In article <KENW.91May15211421@skyler.arc.ab.ca> kenw@skyler.arc.ab.ca (Ken Wallewein) writes: > > Back when I worked with RSX, my impression was that it was one of the >best real-time OSs available. It doesn't seem to have been mentioned here >much lately. Would anybody mind filling me in on why? > >/kenw I miss using RSX. I suppose it's demise can be attributed to two factors. Firstly, the performance PDP and LSI series of processors failed to keep up with the plethora of RISC processors which have come on the market in recent years. Why buy a PDP-11/84 with 0.8 VAX MIPS when you can buy a machine with 10 or 20 VAX MIPS for the same (or less) money? Secondly, the popularity of Unix as a general-purpose OS has lead to the development of several good Unix-like real-time OSs. We've been using VxWorks here for a couple of years. It took some getting used to (what, no AST's??), but I've grown to like it. It's simple, fast, and has some useful features not built into RSX (semaphores, RPCs, TCP/IP support). Bill -- ---- Bill Murphy, Calspan Corporation, Buffalo NY e-mail to: ...!{rutgers,uunet}!acsu.buffalo.edu!planck!murphy%hercules
vladan@idtidt.com (vladan) (05/17/91)
In article <KENW.91May15211421@skyler.arc.ab.ca>, kenw@skyler.arc.ab.ca (Ken Wallewein) writes: > > Back when I worked with RSX, my impression was that it was one of the > best real-time OSs available. It doesn't seem to have been mentioned here The best one was RT-11SJ.
mcculley@alien.enet.dec.com (05/23/91)
In article <KENW.91May15211421@skyler.arc.ab.ca>, kenw@skyler.arc.ab.ca (Ken Wallewein) writes... > > Back when I worked with RSX, my impression was that it was one of the >best real-time OSs available. It doesn't seem to have been mentioned here >much lately. Would anybody mind filling me in on why? > >/kenw Boy, I could discuss this ad nauseum - but that topic tends to have such an effect on me anyway! :-) There are lots of specific factors, but I think they all add up to the fact that a few years ago PDP-11 hardware and software enhancements were seen as less strategic to Digital than other activities. So the business was managed conservatively to promote profitability, rather than aggressively to promote growth. Whether that was a good (or the right) decision or not probably depends on your perspective and the yardsticks you use to measure it. I know that the PDP-11 and RSX business is still producing very considerable revenues for Digital. I also know that there is very little new applications development occuring in this space, which probably accounts for the lack of discussion in this group. Besides, I suspect that the Internet community shares with Digital the trait that I consider the one single biggest factor in the de-emphasis of PDPs: it's what I call "technological chauvinism". The newest technological vogue is by definition the best stuff, right? We all know that the state of the art is constantly advancing so anything old must not be as good as newer stuff... So what if it does the job as well (or better) and more cost-effectively? Enough said, I don't want to get onto that soapbox. We're still around, quietly doing the same job that PDPs and RSX have done for two decades or so. - Bruce McCulley RSX Software Engineering Group Digital Equipment Corporation Nashua, New Hampshire
mas@genrad.com (Mark A. Swanson) (05/23/91)
Yes, RSX is a nice operating system for problems it can handle, which are a constantly declining part of those in our problem space. The old problem with it is the PDP-11's limited address space. I have spent far too many weeks cramming "10 pounds into a 5 pound bag" to voluntarily use it again for any of the problems I deal with. (Most involve some computation tasks which needs to run on the same CPU as the real time application. 64kbytes does not cut it. The need for such computation tasks explains why RSX rather than a simple real time kernel got used.) However, the killers for our use was the fact that RSX had no support for TCP/IP (and for quite a while little for Ethernet), and poor C compilers which made it difficult to work with in the context of larger systems. Mark Swanson
greg@organia.sce.carleton.ca (Greg Franks) (05/24/91)
In article <41618@genrad.UUCP> mas@genrad.com (Mark A. Swanson) writes:
However, the killers for our use was the fact that RSX had no support for
TCP/IP (and for quite a while little for Ethernet), and poor C compilers
which made it difficult to work with in the context of larger systems.
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? :-).
--
Greg Franks, (613) 788-5726 | "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 mcculley@alien.enet.dec.com (05/25/91)
In article <41618@genrad.UUCP>, mas@genrad.com (Mark A. Swanson) writes... >However, the killers for our use was the fact that RSX had no support for >TCP/IP (and for quite a while little for Ethernet), and poor C compilers >which made it difficult to work with in the context of larger systems. > > Mark Swanson There is (finally) a fairly recent release of Digital's PDP-11 C compiler, and there were previously C implementations for RSX from other sources. (In fact, wasn't there one time when the only C compiler was for PDPs, if not RSX? :-) I know that the TCP/IP support has never been a Digital-developed product, but I do know that there have been a couple of vendors supplying TCP/IP that ran under RSX. Of course, these tidbits are probably no help now, but at least they're a sign that the product ain't dead yet...
arl@cs.hut.fi (Ari Lemmke) (05/26/91)
In article <GREG.91May24100015@organia.sce.carleton.ca> 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? :-). Does fortran then do type checking better ? I personally remember project where we used quite large common area ... one programmer of our project had her own ideas how to organize it ;-) No she didn't know how to use 'include'. DEC fortran 'casting' was done with equivalence statements, I remember having 4 statements to program protocols with fortran ;-) > greg@sce.carleton.ca arl // I still like PDP11/23+ & RSX
klaus@captain-crunch.ai.mit.edu (Klaus B. Biggers) (06/05/91)
In article <GREG.91May24100015@organia.sce.carleton.ca> 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.. portability-- what't that? data abstraction-- what't that? what did you use on RSX11?? fortran? -klaus -klaus klaus@snowhite.ced.utah.edu _______________________________________________________________________________
greg@organia.sce.carleton.ca (Greg Franks) (06/06/91)
In article <16302@life.ai.mit.edu> klaus@captain-crunch.ai.mit.edu (Klaus B. Biggers) writes: In article <GREG.91May24100015@organia.sce.carleton.ca> 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, 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. Next, of course, is the issue of "pointer surprise". We had enough troubles with Pascal-style pointers. 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. :-(). If it isn't built into the compiler, it will not be used. 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? :-) Portability is often not an issue with real time systems because it is expensive to change the hardware. 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. 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. 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. Fortran is no better. (I like Concurrent Euclid myself -- real time programming made easy! Who knows, I might even like 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
klaus@captain-crunch.ai.mit.edu (Klaus B. Biggers) (06/06/91)
In article <GREG.91Jun5150023@organia.sce.carleton.ca> 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.91May24100015@organia.sce.carleton.ca> 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 _______________________________________________________________________________
greg@organia.sce.carleton.ca (Greg Franks) (06/06/91)
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