> Well, I suppose RISC is about as close as you can get to > that. Microcode, for reasons best known to someone > familiar with CPU design, is not something > you can just reprogram on the fly...
I beg to differ. As someone who has written megabytes of microcode, including an entire IEEE floating point instruction set, a C machine, a LispKit machine and a large chunk of a graph reduction machine in AMD 2900 series bit-slice ucode (that dates me!) I can state authoritatively that updating ucode on the fly is not necessarily hard. Just because modern cpus don't provide run-time loadable ucode (if anyone knows of present day examples, please let me know) doesn't mean that it's impossible. Indeed, the IA-64 architecture comes damned close to being a ucodable machine, as the assembly language is very low level in many respects. The main reason, IMO, why runtime loadable ucode isn't more widely available is that there is no perceived large market for it. We sold our machines primarily to labs who were researching machine architectures. Some years before that, DEC sold PDP-11/60 boxes with writable control store for organizations that needed fast and custom data capture. The nuclear and particle physics communities loved them. > of it. Now, if all programmers were as concerned about > optimizing code as George is, we > could run Windows XP on a 286 system if you really wanted... > optimized code can do wonders on even the slowest systems. :) Actually, a 286 would have big problems running WinXP, not least because its lack of support for demand paged virtual memory and inadequate kernel/user separation. That's why Linux requires at least a 386. Paul _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
