User:Schol-r-lea/OISC Wars Part 1
N.B.: This is one of a group of forum posts extracted so that the information in them can be re-worked into a less confrontational, more informational set of wiki pages. They are here only temporarily.
For example, you state that Unix, CP/M, and MS-DOS are similar, and influenced each other. This anhistorical assertion seems to be based solely in the fact that they were all text-based, but given the time period, that means nothing about how similar they were, because for all intents and purposes, all systems were text-mode at that time.
The only GUIs which were around before 1983 - the year both the Lisa and the Star were unveiled, and the year Project Athena began as a research project on GUI development - were NLS and the Smalltalk User Environment (and no, I don't mean the language, I mean the environment - the PARC UI came first, around 1970, and the language was named after it in 1972 because it was developed for scripting it based on Kay's experiments with a Logo derivative called Flex at MIT). NLS was an experiment in user experience, and ran on a series of different mainframes (the CDC-160A as a bare system, then a CDC-3100 under what I assume was either MASTER or SCOPE, then an SDS-940 under BTS, then finally a PDP-10 under Tenex, each version being a ground-up re-write in assembly and only the last two being graphical to any real degree). There was a graphical console for the CADR machine (the predecessor of the LMI and Symbolics Lisp Machines), but that was an experimental one-shot system with what was at the time unique hardware, and it was only graphical in that it could render graphics. There was the LINC-12, which was similar, though that was at least mass-produced. Similarly, there were graphical programs for some PDP-10 mainframe operating systems such as ITS, WAITS and Tenex, but they were also experimental things that used specialized consoles and needed to be scheduled so that all the timesharing users could be kicked off while the experiments were running; their main method of use remained text-mode.
And finally there were were the early microcomputers, most of which had a graphical mode, but because they mostly used television sets as monitors, the resolutions for the non-text modes weren't suited for text display, hence the need for two or more modes.
That's about it. Graphical displays were a rarity, and graphical user interfaces were still basically experiments, even as Xerox and Apple began trying (unsuccessfully at first) to market them.
So much for text being a similarity. Unix and MS-DOS were nothing alike in most other regards. For example, Unix, which was based in Multics in many ways but eliminated some of the 'vital parts' (hence the punny name - 'eunuchs', get it?), was a multitasking OS from the start, something which was crucial in the entire 'IPC through pipes' shenanigans. So why did they both use similar command line systems? Well... they didn't. MS-DOS borrowed some things from Unix later, but initially they were completely dissimilar. One can argue that MS-DOS copied CP/M, but trust me, CP/M didn't copy Unix - Unix was an obscure oddity when Kildall started work on CP/M in 1974, and the main influence on it was Tenex, not Multics.
If you still really think MS-DOS and Unix were similar, I dare you to run a Bourne shell script from that time period on an MS-DOS machine of any period without a specialized interpreter.
The claim that MIPS is similar to x86 is simply bizarre, and indicates a genuine lack of understanding of CPU architecture. Seriously, how anyone could find anything similar between the mess that is the 8086, and the remarkable (if perhaps excessive) minimalism of the MIPS and DLX designs, even as compared to OISC, is beyond comprehension. Name even one aspect of them that is similar that cannot be found in every actual CPU architecture after 1970, and I will be amazed.
No, OISC doesn't count - it is, believe it or not, actually emulated in microcode in every conceivable hardware implementation, because (as I learned the hard way when entertaining my own flights of fancy in this arena) real hardware needs registers. Any Turing complete computing machine based on the Random Access Machine model that doesn't use registers explicitly will need to have microcode to use them implicitly, period, end of subject. This isn't something you can handwave away - Subleq is not a simple instruction, and there is no way to implement it as one. It is an intrinsically compound operation, one which actually hides very real complexity.
In any case, what does the CPU architecture have to do with the price of chewing gum? NONE OF THIS IS RELEVANT, because all of this is buried under mounds and mounds of software - software like the BIOS, which is only 'hardware' in that it is stored in a permanent or semi-permanent medium (hence 'firmware'). Firmware is still software; it's just software that is embedded into how the hardware runs, and can know details about the hardware that are less discoverable without it. It doesn't do anything that can't be done in software that isn't stored in Flash memory, and due to the historical development of the PC, it isn't a particularly good set of programs.
CPU architecture has next to nothing to do with the complexity of the operating systems and development tools. You seem to think that you can scale some implementation of Subleq as an FPLA or a strung-together pile of TTL tinkertoys into something that can complete with CPUs implemented as 22nm integrated circuits, or else that someone is going to front the $5 billion it would cost for a silicon implementation to be brought to life - and that is the most outrageous part of all of this. Even assuming that were true, how would it make coding in a language like C any different? Even for an OS, most C code is going to be the same no matter the hardware. You simply don't seem to have thought any of this through.
