What ever happened to Tandem and NonStop OS 2014

I gave up a long time ago. Her persistent "I refuse to understand anything that's not TOPS-10" certainly drove me to killfile a well-meaning, (mostly) on-topic, non-troll newsgroup regular for the first time in years.

As someone who's been an OS writer and has dealt with compiler front-ends and code-generators...

I've always maintained that this "OS mentality" vs "compiler mentality" stuff is bullpoo.

There is a "high-consequence software mentality" (this stuff might break - let's do it right first time) and there's a "lash it together mentality" (it doesn't matter if this crashes - it's either ad-hoc or so easy to fix).

In the same way there's a "systems software mentality" (oriented towards thinking about 'la machine' and how to best use it -- efficient algorithms and data structures and robustness) vs an "applications software mentality" (oriented towards user interaction, real-world logic, and ease of use)

And finally, there's a "resource constrained environment" (every byte-CPU cycle is sacred) mentality and an "it's all free" one (it's all either virtual or I have such a big machine that I needn't consider it).

The three are orthogonal, and different types of programming sit in different niches in that space. For instance, a lot of 70s CP-M applications stuff was low-consequence (or at least developed that way), application-oriented, but resource-constrained (with clever use of overlays and so on).

I'd certainly place embedded cross-compilers and embedded operating systems in the high-consequence (do you want to stand in a freezing car park in Sweden and take off 300 car-doors and replace an ECU because someone chickened up?), systems-oriented (anyone working on code-gen has to know the machine architecture intimately), resource-constrained (every byte of ROM and RAM is sacred - I know of one automotive ECU in production that has 1 byte of spare RAM and over 99% peak CPU load... - to achieve that your compiler needs to know all the tricks!)

To do some things well you need to bring BAH's "compiler thinking" and "OS thinking" together. Unix is a great case in point. In many cases, Unix avoids using clever algorithms ("os thinking") because data structures have been designed to make everything data driven ("compiler thinking").

Inspired by that approach, we took a "dumb code; smart data" approach in designing several embedded real-time operating systems; statically generate and compile the OS configuration and even parts of the API, applying all manner of interesting optimisations, but make the actual core kernel code tighter than a gnat's chuff in terms of both speed and size. Compiler thinking or OS thinking? BOTH. A good software engineer knows both of these spuriously-divided disciplines, and uses the synergy between them.

pete --