22 Sep
2001
22 Sep
'01
2:32 a.m.
Tony Duell wrote:
<snip>
Yes, the distinction is unclear in some cases, but not at the levels your trying to
fit these terms into.
Micro-instruction technically speaking. The PERQ takes several microinstructions to
read main memory, while an assembly level instruction may perform several memory cycles
per instruction.
There is an huge, and very clear difference here.
<snip>
I have no idea Tony. But I've written microcode, and also assembly level code.
There
is a vast difference between them.
<snip>
While the line
between assembly code and microcode is often grey, when it
Ah, you've finally admitted that the distinction is somewhat unclear in
some cases. This doesn't make the terms 'machine code' and
'microcode'
useless of course, but it may also mean (and does IMHO) that the PDP11
emulator that started this thread can be considered to be microcode. takes more
than an instruction to read main memory, chances are your at the
'Instruction' or 'Microcycle'? Technically it takes one microinstruction
to get a PERQ to access memory, but several microcycles. You have to set
up the address, execute the memory read microinstruction (which sets a
state machine running to do the memory access) and then read in the data
on subsequent microcycles. Suppose I write a PDP11 Emulator program for the
Pentium. But this one is
a little strange in that it uses hardly any RAM on the Pentium bus (maybe
a couple of K for a stack and state varialbles, and so on). It expects to
find a few I/O ports in the Pentium I/O space that are linked to normal
RAM (say 22 bits output for the address, 16 bits out/16 bits in for the
data, and a few control lines). It accesses the user program in that
memory by executing several I/O instructions on the Pentium (and other
instructions besides). It outputs the address, fiddles with the mrmory
control lines, reads in the data word.
The point here is, your running assembly-level instructions that are implemented with
true microcode already. So you clearly are not writing microcode, your writing assembly
level code for a Pentium. This is totally clear in your first sentance above!
I now take a bare Pentium CPU, stick it on a PCB (with
the clock circuit,
etc), add this 'emulator' in a ROM on the Pentium bus, and then add the
I/O ports accessing memory.
Is that emulator now microcode by your definiton? If not, why not?
No, its not microcode. Its an assembly-level program that emulates a PDP11.
Why not?
Because there already is microcode running, or your Pentium cannot run your assembly
level program. Whats unclear here?
If you want to run microcode, fire up a PERQ. If you write assembly-level programs for
a Pentium, your writing an assembly level program, not CPU microcode.
Once again, these terms have definitions already. Learn them, and use them correctly,
please.
<snip>
I suppose this
completely depends on which books you have read.
Eh???? Which books do you think I've read, then? Not to me it isn't, and I don't have any
problem with understanding
hardware at the gate level (or below).
-tony
Sorry, I don't seem to be able to help here.
All I can say is that your useage of the terms is totally incorrect as they are used by
people who write both assembly-level and microprograms. There is a full order of
magnitude of difference in the degree of hardware abstraction between these two very
different forms of programming.
It appears to me that your trying to defend the incorrect usage of a cool-sounding term,
you clearly have some emotional attachment to.
As this list is about computers and their technology, I wanted to step forward and
correct this misuse of terms to prevent others from learning a highly incorrect usage
that can only sow more confusion.