|
![](/i/fill.gif) |
Invisible wrote:
>>> Well, a "ROM" can be just a grid of wires, some connected and some not.
>>
>> Yes? I was saying something with a program counter that runs mulitple
>> instructions per CPU instruction would count as microcode, regardless
>> of how you stored the code it's running.
>
> So if it doesn't use a counter it's not microcode?
That's just *my* definition. If it doesn't have something serving as a
program counter, I wouldn't classify it as "code" instead of "logic". In the
case of the 6502, it's pretty clear that the T1 thru T6 lines act as a
program counter, and the other bits are acting as the code.
> As you say, we're just arguing about semantics now. I always thought of
> microcode as being a block of ROM (or even some kind of EPROM) which
> actual address decode circuitry, so that you can execute jumps and so
> forth.
Basically. And normally its instructions are wide enough to have one bit per
gating signal inside the CPU (so, a line for "register 1 reads bus", a line
for "register 2 writes bus" a line for "R3 writes to address bus" a line for
"PC reads from data bus", along with selecting the proper ALU unit, etc. So
microcode is not uncommonly 100's of bits wide. And it usually has the new
Micro-PC in each instruction too, so every instruction is a branch.
> By contrast, the CPU I'm designing has no such thing. It's just
> that on each clock pulse, a different control line becomes active, and
> that line connects to one or more control lines (possibly via logic
> gates that pass the signal only if the opcode has certain bits set). I
> wouldn't call that microcode; it'd call that "a custom arrangement of
> gates".
I agree. There's no code there. You have hardwired logic.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
![](/i/fill.gif) |