Misuse of word "microcode" 103
 |
George Neuner Legend has it that Apple negotiated with Motorola about putting special instructions in microcode for use by Quickdraw. Motorola was reluctant, and about the time that Motorola gave in...
Morten Reistad
My quick impression of "real microcode": (partly tongue in cheek)
What do you mean by "different microcode"? On the 360-30, you could select some options on the console and you would...
1. It lives in expensive memory that is: - faster than main storage - wider than main storage - if possible a really strange number of bits wide. :-) 2. It has no privilege model, i.e. no distinction between user and system contexts. If you can run it, you can clobber the machine. 3. It is only writable by Real Programmers. 4. It is capable of expressing more parallelism than the public instruction set of the machine. 5. It is not well suited to modular programming idioms like nested subroutines, argument pbutting, and indirect addressing. 6. You would rather program the machine in something else. 7. The microinstruction format has been designed specifically to implement a macroinstruction interpreter efficiently on the chosen hardware rather than with general purpose computing in mind. It is also easy (sometimes trivial) to decode. 8. There is little or no variation in end time of microinstructions. 9. It's a mythical place where if you were allowed to write handlers for custom instructions, your program would suddenly run fast enough, except you can't, so it's not your fault it's slow. :-)
The 6502 scores on point 2. and maybe points 3, 5 and 6 depending on who you ask. :-) It fails big time on 1 and 8. 7 is interesting - apparently the 6502 was a fairly good fit for tokenized BASIC because of its interesting addressing modes. I personally liked the 6809 better, except for the big-endianness...
Sometimes an instruction set is called "microcode" mostly because you don't want ordinary people to write programs in it. Witness the low-end IBM 360s with the 8-bit ALU and very vertical microcode stored in main memory. Allowing-encouraging people to write in the native code for that machine would have: - broken market segmentation because you would get more bang per buck than you get running 360 code on it - created support headaches - weakened the marketing picture that everything is compatible across the product range.
Jason Ozolins That was probably me. Microcode still makes sense as a way to achieve cross-cpu-model compatibility, but when somone...
There was a thread on comp.arch a while back asking "why don't machines these days have writable control store?", to which someone replied, "it's called L1 cache these days". I tend to agree.
-Jason =:^) ------------ And now a word from our sponsor ------------------ Do your users want the best web-email gateway? Don't let your customers drift off to free webmail services install your own web gateway!