First, the point about XP running on a 286 if it were optimized... I was being facetious. Didn't think people would take me literally. That being said, I'll modify that and say it could run on a *386*. :)
Maybe we're not understanding what is meant by "microcode"... The only CPU I've designed was a 4-bit system that didn't use microcode to get it's work done (it was for a class), so I can't claim direct experience, but I at least thought I knew what the word microcode implied... a level of abstraction, if you will, between the opcodes and the actual hardware... a reduced instruction set sitting there that could take some of those complex codes and break it down into the fundamental instructions. Anyway, that's why I said that a RISC processor has more flexibility in that regard, because you have a near 1-1 corellation with the opcodes and what the CPU is directly capable of, and any higher level things you want to do are up to the programmer. So, that was my understanding, at least, but if I'm wrong then I suppose it'd be good to be educated. :) Aaron ----- Original Message ----- From: "Paul Leyland" <[EMAIL PROTECTED]> To: "Aaron Blosser" <[EMAIL PROTECTED]>; "Mersenne@Base. Com" <[EMAIL PROTECTED]> Sent: Tuesday, October 16, 2001 8:45 AM Subject: RE: Mersenne: Re: AthlonXP > 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
