"Pure", "No check of the OS at all.."?
No, the only constraint I know of is that they can't be self modifying (and any programmer that uses that trick deserves to be flogged).
No, not quite. Except you understand "self modifying" different from me. A program consists of three types of "memory regions", "code", "data" and "blank space" (bss). In principle, you can write to whatever region you like, but "code" usually contains the program binary, and modifying that by the program is what I would call "self modifying".
Unfortunately, that is only necessary but not sufficient for a program to be pure. It also must not write into the data or bss section, which - apparently - is not granted for your average program. Of course your average program wants to write to its data region, which typically contains C variables with program linkage (aka "global variables"), and of course, you want to write to the bss space (otherwise, it would just stay blank.).
So "pure" programs have to be a lot more careful. You essentially cannot use variables with program linkage (including library bases!), everything must be on the stack, or you must allocate from the heap yourself.
Some compilers come with startup code that create on each program start a copy of the data region on the heap, including manual relocation of the copy of the data space. Needless to say, while this makes programs pure (most of the time at least), it also causes additional overhead.
Ideally, there would always be a background process keeping count of they alloted timeslices that each process was allocated.
Why do you need a process for that? And keeping track of each single piece of memory a program allocated is usually too much overhead in first place. The way how Linux works is quite different. Every program gets its own heap, and can do with this memory region what it likes. The program usually includes compiler library routines that implement memory allocation from the heap. This memory allocation is not by the Os. The only exception is when the heap gets too small and requires resizing. Linux (and *ix operating systems in general) usually have a brk() or sbrk() system call to do that. But that's not a "memory allocator". It is usally several layers below malloc(), which is a C standard library function for maintaining the heap. If the program ends, the entire heap is thrown away. If you start a new process, i.e. by the (infamous) fork(), the heap, stack and code are duplicated, and the separate copy continues execution behind fork(). (Actually, this is usually not a true copy, but rather depends on the "mad cow" trick, i.e. "copy on write").
What I'm talking about does bring a few constraints to programming, but its also a lot tighter OS.
Which makes it rather hard to implement any C type language on top of it, i.e. the "pureness" you seem to require. Bad idea, if you ask me.
BTW - Since I have a Coldfire development platform on hand, I'm thinking about working on a kernel with that.
If I may, I would probably suggest a good book on operating system design.
