Re: NOPs, odd bits, timings

[Christophe Lavarenne <Christophe.Lavarenne@xxxxxxxx>]

> Does anybody know what an MuP21 does when it executes an invalid opcode?

Chuck says that the behavior of invalid opcodes is undeterminate.
The only way to know, would be to look at the MuP21 chip layout.

> NOPs do nothing to save power, as far as I can see.

NOPs consume slightly less power than other instructions because the stacks
are stable (and the ALU too after the carry chain has settled), so no
transistor is switching there, which means with CMOS that only a very small
leakage current is consumed. But the instruction decoder, the instruction slot
sequencer, the program counter incrementer, the address decoder and memory
timing generator are all running and consume power to fetch and execute
instructions, even NOPs.

A NOP just consumes one instruction slot an cycle with no other side effect.
  Consuming instruction slots is usefull to reach the next word boundary,
which is required for branching instructions, either because branch target
adresses are word aligned, or because branch instructions must be in the 1st or
2nd slot not to interfere with the 10 bits target address in the 3rd and 4th
slots.
  Consuming instruction cycles is usefull either to let the carry propagate
and settle while the T and S registers are stable, or to tune delays between
memory accesses to memory mapped I/Os, or occasionally to let signals settle as
for example to correct the A! timing problem of the early MuP21s.

> The inversion of odd address and data bits is rather confusing.

No more than the conversion between binary/hex/decimal.
The confusion maybe comes from the way some cross-compilers are written.
Forget bit inversions until you want to transfer your cross-compiled code/data
to real memory, and only at that moment invert odd data and address bits.
A compiler run by the MuP21 itself does not have to care about bit inversions,
exactly as you don't care the voltage encoding of bits on other processors.
The only moments when you have to care is when you are accessing external I/O,
or when you are looking at the MuP21 pins with a scope.

> If I were to add inverters to the odd address pins and two-way inverters
> to the odd data pins, then would ALL of the inversion mess go away?

Yes, but then the odd pins would be slower, and therefore all the chip would be
slower. Why pay continuously at runtime what you can do once at compile time?

> If I use the fast I/O space for 15ns sram hookup, and run a program out of it
> (I know the program would have to be <1k), will the program run faster, since
> it does not have to access relatively slow dram?

Instructions and data fetches from fast RAM will be faster, but data fetches
from DRAM, slow I/O or byte memory spaces will still have their corresponding
timings, because the MuP21's memory timing generator is driven by the address
decoder, which also drives the different chip selects.  

CL