microcoding a PC into a PDP-11 (was: RE: Classic Computers vs.

Bob Shannon wrote: [stuff deleted] your assembly I'm reading this as suggesting that if any of the logic used to deliver a set of abstractions is soft then the next higher level of abstraction (which is _usually_ the ISA of the processor) cannot be considered microcode. That might be a useful metric, but, as you acknowledge, nanocode exists, so the utility of this metric as a definition of microcode vs. something else is at least suspect. programs for them correctly, Well, here's _one_ textbook definition of microcode: "...programming that is ordinarily not program-addressable, but, unlike hardwired logic, is capable of being modified..." which says nothing about other levels of microcode, nor about the complexity of the abstraction on which the microprogram executes. It's notable that IBM uses the "well-defined" term "microcode" to describe what most of us would consider "firmware". The definition of microcode can certainly be fuzzy, and Tony has already postulated an implementation using processors rather than discrete logic or bitslices that would meet the definition above. code. There I'm fairly certain most of us have written both, and this thread is prompting some of us to ask just _what_ the real difference is between the two. Thus far I've seen two arguments advanced as to why what is being described is an "emulator" rather than "microcode", and they seem to revolve around two arguments: - It can't be called microcode if there's microcode beneath the abstraction at which you're coding. Obviously this one can be dismissed by using a non-microcoded processor as the functional unit. - There is some level of hardware abstraction above which it can't be considered microcode. I'm not sure how this gets translated into a quantitative metric. It's can't run on anything more complex than a sequencer? By that definition the code on the K6 isn't microcode, it's an emulator. Execution of an "instruction" takes more than one memory cycle? Given speculative fetching of blocks of memory on contemporary processors it's possible for an "instruction" to execute with zero memory references. It's just "too complex"? By that definition the B1700/1800 didn't have an assembly language. What other characteristics might be used as metrics? Long instructions words? There are certainly VLIW machines out there, so that doesn't work. The need to "carefully" schedule instructions? That demands certainly exists in some implementations of some RISC ISAs. I'm having trouble seeing hard-and-fast rules here. they are used by Well, I've done both, and at this point I can hardly agree that Tony's usage is "totally incorrect". Which takes me back to the K6. A die with dual RISC processors running code which fetches, cracks and "executes" X86 instructions. By the definition being advanced by Tony this is clearly microcode; by your definition it's not -- it's an emulator -- yet any CPU designer that I know (including myself) would certainly consider it to be microcode. In a purely empirical sense, the appellation "microcode" isn't bounded by the complexity of the underlying hardware abstraction. It's nothing more than part of the logic used to deliver another abstraction. Likewise there's nothing to prevent an "emulator" from running out of control store -- the most absurd of which being machines which performed simultaneous emulations of several ISAs, performing microcontext switching between them. cool-sounding term, Who has an emotional attachment? I've been writing both microprograms and assemhly crap for more than a quarter century and _I_ can't see a clear distinction, and your definition is clearly at odds with that used by IBM -- which at the very least suggests that the term is not as well-defined as you'd like to believe. forward and incorrect usage Thank god you're here! -- Chris Kennedy chris(a)mainecoon.com http://www.mainecoon.com PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97