Paul Wallich wrote:
Martin Gregorie wrote:
On Fri, 22 Aug 2008 22:56:09 +0000, sln wrote:
On Thu, 21 Aug 2008 09:11:48 -0500, [EMAIL PROTECTED] (Rob Warnock) wrote:
[EMAIL PROTECTED]> 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.
I thought microcode was relative well defined as being the software
used to implement instructions that were not fully implemented in
hardware.
http://en.wikipedia.org/wiki/Microcode does not make me think otherwise.
Arne
--
http://mail.python.org/mailman/listinfo/python-list
