Re: NOPs, odd bits, timings

[Eugene Leitl <Eugene.Leitl@xxxxxxxxxxxxxxxxxxx>]

On Thu, 10 Oct 1996, Christophe Lavarenne wrote:

> > Does anybody know what an MuP21 does when it executes an invalid opcode?
> 
> Chuck says that the behavior of invalid opcodes is undeterminate.

Apropos Chuck: Christophe, do you know why all major players (Chuck, 
Jeff) have become so suddenly incommunicado? I must admit, I suspected 
something along the lines of "Hmm, we've got a great design (F21/I21), so 
let's make it entirely proprietary. If we keep still long enough, the 
topic of availability will go away with time all by itself". Of course, now 
that MISC is again up and running, this interpretation seems to have become 
insubstantial... has it?

(I don't want to nag (I'm a Forth fan, after all), but sometimes the 
Forth community displays a lamentable lack of professionality, be it user 
support or delivery on time).

> The only way to know, would be to look at the MuP21 chip layout.

But they do not bring the chip into an undefined state (never-never 
land), I hope? I am thinking about GA-breeding code here (e.g. for 
fractal voice compression). Thomas S. Ray thinks machine code degeneracity 
is one of the sources of program 
brittleness in GA. I am not entirely convinced, but think he's might have 
a point here.

  http://www.lrz-muenchen.de/~ui22204/Zen/Zen.html
 
> > NOPs do nothing to save power, as far as I can see.
> 
> NOPs consume slightly less power than other instructions because the stacks

Only slightly? I might be wrong, but I recall from browsing the archive 
(bandwidth is now _very_ bad in Europe) that the impacts were quite 
dramatic. 50 mW at 5 V is purportedly standard power dissipation (can 
somebody confirm this?), a NOP loop has been supposed to bring power burn 
to just a few mW. I think, operation at 3 V shuts down the video processor, 
thus being the most efficient power saving method. 

Apropos video processor: Christoph, is the MuP21's PAL signal 
standard/clean? (I seem to recall some caveats from the archive...) Do 
you have some PAL code somewhere, perchance?

Let's make a freeware/PD MISC code repository. I'm very willing to 
contribute, once the development has started.

In http://pisa.rockefeller.edu:8080/MISC/latest/8 Jeff has written:


"You are quite right about performance.  Even though the video processor uses
only 25% of the memory bandwidth directly there is a parasitic effect due to
off page memory access.  When both the cpu and the video processor are
running on different pages of DRAM then each video processor memory access
will be offpage and will force the next cpu memory access to be offpage too! 
Thus under these conditions the cpu only gets 1/3 of the bandwidth, not 
3/4."

Is this still true? It seems, turning on video should be made a scarce 
commodity, which is ugly concerning user friendliness.


> 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.

Does not sound too good... If one extrapolates this to 400 MHz at which 
F21 is purported to run, then some kind of sleep mode (in a free running 
processor?? difficult) should be implemented, as power dissipation goes 
exponential with frequency. F21 might be a power hog, unsuitable for 
mobile applications.

[...]

-- Eugene