Subject: Unidentified subject!

From: Andrew Sieber <[email-masked]>
Date: Wed, 09 Oct 1996 16:06:21 -0400

Eugene Leitl wrote:
>- is the MuP21 $350 kit still available?

That kit is now $250.

>- how many days does one wait for delivery?

I mailed my order for the chip and manual on a Tuesday, and they
arrived the following Monday.

>Particularly, high absolute
>performance and excellent MIPS/Watt ratio as well as NOP power saving
>capability are very interesting, since mine is a mobile application
>demanding sophisticated power management.

I'm still not sure I've figured out why NOP gives the ability to save
power.  It seems to me that all you can do is lower operating voltage
to save power.  NOPs do nothing to save power, as far as I can see.

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

The inversion of odd address and data bits is rather confusing.  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?
Would I be able to program it and never have to XOR anything with
AAAAA or worry about the inversion stuff at all?

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?

If these issues have already been covered in this mailing list and
they're stored in the archive, I've had no time lately to read
them, so I apologize if these are repeat questions.

--Andrew Sieber
[email-masked]

---

From: Christophe Lavarenne <[email-masked]>
Date: Thu, 10 Oct 1996 06:10:03 +0200 (MET DST)

> 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

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