The Importance of Terminology's Quality

[Paul Wallich]

Martin Gregorie wrote:
> On Fri, 22 Aug 2008 22:56:09 +0000, sln wrote:
> 
>> On Thu, 21 Aug 2008 09:11:48 -0500, rpw3 at rpw3.org (Rob Warnock) wrote:
>>
>>> sln at netherlands.com> wrote:
>>> *IS* raw machine code, *NOT* assembler!!
>> [snip]
>>
>> I don't see the distinction.
>> Just dissasemble it and find out.
>>
> There's a 1:1 relationship between machine code and assembler. 
> Unless its a macro-assembler, of course!
>  
>> Each op is a routine in microcode.
>> That is machine code. Those op routines use machine cycles.
>>
> Not necessarily. An awful lot of CPU cycles were used before microcode 
> was introduced. Mainframes and minis designed before about 1970 didn't 
> use or need it and I'm pretty sure that there was no microcode in the 
> original 8/16 bit microprocessors either (6800, 6809, 6502, 8080, 8086, 
> Z80 and friends).
> 
> The number of clock cycles per instruction isn't a guide either. The only 
> processors I know that got close to 1 cycle/instruction were all RISC, 
> all used large lumps of microcode and were heavily pipelined.
> 
> By contrast the ICL 1900 series (3rd generation mainframe, no microcode, 
> no pipeline, 24 bit word) averaged 3 clock cycles per instruction. 
> Motorola 6800 and 6809 (no microcode or pipelines either, 1 byte fetch) 
> average 4 - 5 cycles/instruction.

One problem with this discussion is that the term "microcode" isn't 
really well-defined. There's the vertical kind, the horizontal kind, 
with and without internal control-flow constructs, and then there are 
various levels of visibility to the user -- see e.g. the pdp-8 manual, 
where "microcoding" is used to mean piling the bits for a bunch of 
instructions together in the same memory location, which works fine as 
long as the instructions in question don't use conflicting sets of bits.

paul