On 06/01/18 10:40 AM, Lew Wolfgang wrote:
Reduced instruction set CPU's are consistent with the UNIX Philosophy: a function should do only a few basic things, but it should do them very well.
Well RISC is at risk. The origins of the ARM lie in RISC but we've come a long way since then. <quote src="https://www.extremetech.com/computing/187513-why-apple-wont-dump-intel-x86-for-its-own-arm-chips-in-macbooks-and-the-mac-pro"> ... also reprints some laughably untrue assertions about the ARM-x86 comparison, writing “The aging x86 architecture is beset by layers of architectural silt accreted from a succession of additions to the instruction set. Emerging media formats demand new extensions, while obsolete constructs must be maintained for the sake of Microsoft’s backward compatibility religion.” </quote> Also https://www.androidauthority.com/arm-vs-x86-key-differences-explained-568718... Many years ago I worked with an English Electric 800 Series computer. It was all transistors, an asynchronous CPU, and was FAST! It did only have 16 opcodes They were hard-wired, not microcoded. I never peered at the logic and it must have been frightening. But it really really was just 16 instructions. I think it was a 803 with 39 bt words that contained 2 16-bit instructions (or one plus an address parameter). IO was TTY and paper-tape. Later models upped the instruction repertoire to 64 to do more things with arithmetic like 'negate and add', but model I had worked n 16 instructions. OK, one was "DO IO" which was ... complex ... but hard-wired. If you've read Knuth you'll be aware that you don't need more than those 16 opcodes. See the MIX assembly language, which, sadly, multiplies them out when it comes to writing, because of the way modifier works, so there are a half dozen ways the LOAD command can work. Again, in "Algorithms and Data structures = programs" there is a true RISK VM model in the PASCAL interpreter. The main difference between Knuth and Wirth is that the latter works with a single register machine, Europeans being more parsimonious in their architecture than Americans, who preferred multi-register machines, and as a side effect, the compiler parse tree is easily translated into reverse polish which is suitable for a single register machine. If you are going to throw compiler optimization at things, the RP/single register machine is very, very easy to optimise code pathways for, no need to worry about register allocation & dumping strategies (and less context to save on interrupts!). You can make the compiler small and fast; or you can make it capable of doing more global optimization and probabilistic execution tree-branch analysis. Some of there attempts at RISK were based on the idea that now there was so much silicon on the chip freed up -- oh, wait, we've moved on from transistors and are playing in a new field -- that the machine can now have lots of registers. One model was actually a zero-register concept with everything being indirect and the working memory being on chip. Dealing with interrupts means simply switching the register bank pointer. Silicon real estate was cheap; heck today its even cheaper and that kind of RISK makes more sense now. A variant of this is https://en.wikipedia.org/wiki/Register_window The SPARC architecture also makes use of a lot of registers and modern silicon fabrication can work on the initial spec to offer even more. <quote src="https://en.wikipedia.org/wiki/SPARC"> The SPARC processor usually contains as many as 160 general purpose registers. According to the "Oracle SPARC Architecture 2015" specification an "implementation may contain from 72 to 640 general-purpose 64-bit" registers.[3] At any point, only 32 of them are immediately visible to software — 8 are a set of global registers (one of which, g0, is hard-wired to zero, so only seven of them are usable as registers) and the other 24 are from the stack of registers. These 24 registers form what is called a register window, and at function call/return, this window is moved up and down the register stack. Each window has 8 local registers and shares 8 registers with each of the adjacent windows. </quote> There is also mention in the above that "Several fully open source implementations of the SPARC architecture exist". https://en.wikipedia.org/wiki/SPARC#Open_source_implementations Those seem to be 'designs' rather than 'in production'. I suspect, however, that if we were to drive for an implementation of the SPARC we might as well go the whole hog and go for the <quote src="https://en.wikipedia.org/wiki/UltraSPARC_T2"> Sun Microsystems' UltraSPARC T2 microprocessor is a multithreading, multi-core CPU. It is a member of the SPARC family, and the successor to the UltraSPARC T1. The chip is sometimes referred to by its codename, Niagara 2. </quote> And at https://en.wikipedia.org/wiki/UltraSPARC_T2#Open_design <quote> On December 11, 2007, Sun made the UltraSPARC T2 processor design publicly available under the GNU General Public License via the OpenSPARC project. The release includes: Verilog RTL source code of the design Verification environment Diagnostics tests Open source tools, scripts and Sun internal tools needed to simulate the design ISA specification (UltraSPARC Architecture 2007) Solaris 10 OS simulation images </quote> I'm not aware of any FOSS implementation. </quote> We had the Elliott Algol compiler was co-written by C.A.R. (Tony) Hoare. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org