Re: Forth as an operating system

Elizabeth D Rather wrote:
Well, in the 70's and early 80's I worked on a lot of data processing-type programs on minicomputers supporting multiple (up to 64) users on dumb terminals. It was not an embedded system in the sense of being a control/data acquisition-type app, more of a database, but it was at least dedicated to running all somewhat-related Forth applications, not random programs in whatever language from whatever source.

I'm not sure what the point of your response is.

My message was about two broad classes of systems: Systems designed for a specific purpose and systems that are general purpose. I used "embedded systems" and "desktop/server systems" as two obvious examples of each class. But I guess you wanted to point out the totally unremarkable notion that there are blurry boundaries there. Congratulations for stating the obvious.

You've described a system designed for a specific purpose-- running some sort of multiuser database application. The fact that you aren't sampling an A/D converter or driving a stepper motor doesn't take that system out of the realm of what I was talking about. Using cooperative multitasking on such a system also makes sense, again, because the system has a dedicated function. And in that application, I'll bet that you didn't have people doing things like *significant* software development on the same system while it was running. Unless the customer was okay with up to 64 users facing occasional downtime caused by the odd typo, ! to hardware that shouldn't be touched, failure to release the CPU, and assorted other human errors that happen during development and testing.

For non-dedicated environments where a single machine will be used for a variety of general purpose tasks, such downtime isn't usually acceptable, and that is one thing that drives the need for preemptive operating systems and things like protection mechanisms.

But let's get concrete. The message headers from you indicate you're using some flavor of Windows to read this message. And if you're like most Windows users, you enjoy the ability to pick and choose your hardware and software. Maybe you use Office, but you could also choose one of the many alternatives. Maybe you play MP3's in the background while you're working-- and you have a lot of choices there as well, both in media players and hardware to hear the music on. Maybe you sometimes browse the web. Maybe you create presentations. Maybe you edit video. Oh, and you probably write some Forth code too.

So there you are with your general-purpose PC sitting in front of you, offering you the ability to choose hardware and software freely and move between *wildly* different tasks that the hardware designers may not have even predicted. I want you to tell me that you seriously believe that a system built around the end user's *arbitrary* whims and *free* choices in hardware and software (and language for software) could effectively be managed with a purely cooperative multitasking system. Please factor in a pragmatic appraisal of how people are in real life, not some idealized "if everyone just follows the rules, everything will be fine" naive optimism.

If your answer is yes, then you're unreasonable, or at least you're willing to put up with a highly unreliable system. Most people aren't. Most people don't want to have their desktop system go down (along with all their other work) because a bug wasn't found during testing, or because in some marginal case a task failed to yield cycles back to the CPU.

If your answer is no, then you've validated a major part of the reason why preemptive multitasking operating systems exist-- for general purpose computing where the end user is freely making choices and still wants a reliable system.

Systems that are built for specific purposes... or that restrict hardware choices... or that limit what software can run or what you're allowed to do (such as no software development on a running system)... or that say you must stick to a single language... the more areas in which one can take a system and fix choices, the better cooperative multitasking works.

Or put another way, it should be completely unsurprising to everyone that a multiuser database system could be written in Forth using cooperative multitasking techniques. What would be very surprising if you believe that *same* system could be used to reliably do other concurrent things based not on carefully designed and testing software that was validated by system-level testing, but on the end user's whims and choices. For example, what would be astounding would be if you told me that you would have 63 users on that system all happily accessing the database while at the same time one user who is learning Forth, sitting an an ok prompt, freely writing routines that may block, trash state because of accidentally swapped arguments to !, and other very human errors.

Well, a lot of systems I've worked on have been in research environments where scientists will, indeed, bring in strange devices that we never heard of. And sometimes they wanted to write the software, too (with or without assistance).

And in these environments, it was probably understood that while Dr. Smith is hooking up the XYZ2000 to the system and writing some routines to access it, the rest of the system might come to a crashing halt, be unresponsive, or do other unpredictable things. If you allow for the system to be unreliable during such development and testing, then sure, cooperative multitasking is perfectly fine. If this is unacceptable, then Dr. Smith needs to do his development and testing when the rest of the system isn't in use-- in other words, dedicate the system for a specific purpose for a time.

The essential thing in cooperative multitasking is the word, "cooperative". This means that whoever is writing code for it or plugging in devices must promise to follow the rules and play nice. You don't need to personally have 100% control, if your colleagues will also assume responsibility.

It's not just about responsibility and "playing nice." Last time I checked, humans make mistakes, even when they are sitting up straight and following the rules. People forget. People get distracted. People make assumptions that are false. People had too many carbs for lunch and aren't thinking clearly. People screw up for an endless number of reasons, not just because they are stupid or lazy, incompetent, or irresponsible.

Testing can find most of this. But not all. Forth doesn't remove the human element from programming. In fact, it amplifies it.

In my world of cooperative multitasking, the rules are very simple: if you perform any I/O, you relinquish the CPU for as long as it takes for the I/O to complete. If you have a lengthy CPU-intensive operation (hairy math, big sort, etc.) you're responsible for briefly relinquishing the CPU at fairly frequent intervals. Providing everyone who writes code for this box will accept responsibility for following those rules, and test their code & devices reasonably, it'll work fine, whether the environment is a desktop or real-time funky hardware setup.

I like your caveat. It's kind of like saying, "if everyone who lived in this city acted responsibly and always did the right thing, then we wouldn't need laws, police, or a judicial system."

Again, a big problem here is choice. Let's assume the best-- that everyone is responsible, follows the rules, and reasonably tests their hardware and software. You used the word "reasonably". Tell me what "reasonably" means when I can go to my local computer store and freely choose from at least 25 different motherboards, maybe a dozen different CPUs, endless memory configurations, videocards that range from simple frame buffers to high-end graphics accelerators, sound devices that range from monophonic to eight speakers, and endless combinations of peripherals. And I haven't even gotten to the software yet and the nearly infinite ways I can pick and choose and configure code.

What does "reasonable" mean in that kind of environment? Without resorting to wild arm waving, explain to me how such an environment could *practically* work with cooperative multitasking and a lack of protection mechanisms. What would be the method end users would use to ensure that their arbitrary and free choices were "reasonably" tested? Is it a stamp on the box from a certification lab? Is it the company proudly flying some kind of banner that says they're now ISO-9000 (or whatever) compliant?

That's a big problem here in comp.lang.forth-- people will issue statements like "if everyone just tested better and followed the rules" and pretend that the underlying human issues simply go away. Yet I'm willing to bet that if the general public had access to Forth, Inc.'s internal bug reporting system we would find a non-zero number of bugs in released software. Gosh, how did that happen? Were your staff not testing and playing by the rules?

It's actually pretty hard for most programs to do much without some kind of I/O: reading/writing disk, screen, playing music, whatever.

And it's pretty easy for even the best people to make mistakes.

What I really hate about this thread is the not-so-hidden statement that the choice of cooperative multitasking verses preemptive multitasking is a choice between responsibility and irresponsibility; between diligence and laziness; between design and chaos. Why can't it be seen as a choice between optimism and pragmatism? Why can't it be seen as a choice between attacking the problem of reliable systems from two different perspectives, each with advantages and disadvantages? Why can't the issues here be discussed without arm waving and ignoring human psychology?
.

Relevant Pages

  • Re: Forth as an operating system
    ... And if you're like most Windows users, you enjoy the ability to pick and choose your hardware and software. ... I want you to tell me that you seriously believe that a system built around the end user's *arbitrary* whims and *free* choices in hardware and software could effectively be managed with a purely cooperative multitasking system. ... If this is unacceptable, then Dr. Smith needs to do his development and testing when the rest of the system isn't in use-- in other words, dedicate the system for a specific purpose for a time. ... But there is an important element of personal responsibility involved; a general-purpose OS has to contend with not only irresponsible idiots but malicious hackers and students trying to crash the system for fun. ...
    (comp.lang.forth)
  • Re: Getting that Amiga Advocacy FAQ going.....
    ... Amiga, its users and so on would be handy for anyone who wanders ... Windows 98, NT, 2000 on their older hardware? ... software at 10X the fastest 68K speeds a reason? ... My apps are more recently updated than their original releases. ...
    (comp.sys.amiga.advocacy)
  • Re: 32 bit architecture advice (ARM, PPC etc.)
    ... I'd be instantly biased towards ARM for that reason only. ... with hardware and do software mostly but still design hardware). ... Intel support here in Brazil has been damned bad (I started with ... Motorolas iMX based ADS - and their support was quite opposite to ...
    (comp.os.linux.embedded)
  • Re: Need tutorials, guides... However...
    ... The main reason for me to learn assembly is that i want to make ... performance loss you'll get from an OS like Windows or Linux. ... machines out there have gone off in many different directions. ... expect to find certain hardware at certain addressess. ...
    (alt.lang.asm)
  • Re: Upgrading from Etch to Lenny
    ... stick with stable, unless there is an important reason. ... It also depends on what hardware, ... suggesting that a newbie should be given some pause on that. ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    (Debian-User)