That's not the 'dictionary' definition, which is 'separate paths for instructions and data'. But let's go with the 'no self-modifying code' one for the moment. The thing is that self-modifying code is pretty much an artifact of the dawn of computers, before the economics of gates moved from that of tubes, to transistors, and also before people understood how important good support for subroutines was. (This latter is a reference to how Whirlwind did subroutines, with self-modifying code.) Once people had index registers, and lots of registers in general, self-modifying code (except for a few small, special hacks like bootstraps which had to fit in tiny spaces) became as dead as the dodo. It's just a Bad Idea. The people who built Unix were fundamentally very practical. Self-modifing code is not 'practical'. (And note that Unix from V4: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c onward has support for pure text - for practical reasons). You could say that of a zillion computers. The only recent computer I can think of offhand with separate instruction and data paths was the AMD 42K (nice chip, I used it in a product we built at Proteon). They had separate ports for instructions and data purely for performance reasons. (Our card had a pathway which allowed the CPU to write the instruction memory, needed during booting, obviously; the details as to how we did it escape me now.) s/70/45/. And the other -11 memory management (as on the /40, /23, etc) does allow for execute-only 'segments' (they call them 'pages' in the later versions of the manual, but they're not) - again, separating code from data. Unix used this for shared pure texts. And note that those machines with separate I+D space don't meet the dictionary definition either, because they only have one bus from the CPU to memory, shared between data and instruction fetches. Noel