Let's say I want to put a 65x processor into a "waiting" state. Are some NOPs less power hungry than others, or are they all the same?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

What I'm probably going to end up doing eventually is interleaving useful work for other calculations into where those NOPs used to be. WAI feels like overkill when I only need to wait a small number of cycles for a multiplication operation to complete. Once we have a visual65816 perhaps it will be easier to see the answers to these questions.

I'd be looking at the decision in a somewhat different way. Regardless of whether it's a small number of cycles or a large number of cycles, you're still faced with the question, "What's the best/easiest way to accomplish this?" And I suspect you'll find that using WAI is easier than somehow inserting a number of NOPs. But I encourage you to try both approaches (on paper, at least.)

Edit: will the number of cycles be known beforehand? If so, then inserting NOPs is easier. Or, is the number variable, becoming known only at runtime? In this case I expect WAI will be easier.

Also; paraphrasing what Garth said, most of the power consumption is going to be related to bus activity. And bus activity continues during NOPs, but not during a WAI. Since you only need to wait a small number of cycles, wouldn't you say the issue of power consumption during this time has negligible importance?

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've considered ganging (and stacking) three 4 bit counter chips such that a specific address strobe stops the processor clock for 1024 phases (512 clock cycles). Other strobes may stop the processor for a shorter period. Does this save energy? It depends. If I never use the feature then definitely no because I have three chips all with one high frequency input which aren't doing anything useful. Furthermore, clock phase trickery usually requires a double frequency clock. That definitely doesn't save energy.

WAI, if available, probably saves energy because it avoids an external, high frequency component and a double frequency clock. If WAI is absent, does NOP use less energy than, for example, ORA #0 or EOR #0? Very probably yes. An idle ALU cycle probably uses less energy than a dummy ALU operation. However, does a two cycle NOP in 65816 emulation mode use less energy than two single cycle NOPs in 65816 native mode? Both incur two read cycles but native mode advances the program counter faster.

If you are very concerned about energy consumption, you should definitely avoid GALs which may consume more than 100mA idle to obtain propagation delay of 7.5ns or less. Likewise for detailed memory maps. RAM lost to coarse address decode may save energy because it reduces high frequency address decode logic. It also allows faster execution while peripherals are active. One exception is RAM used as storage cache. This is surprisingly common and there are cases within cases. A long time ago, I had the opportunity to upgrade a 64MB RAM Apple laptop with either 256MB of two cycle memory or 512MB of three cycle memory. The larger, slower memory notably improved battery life because it reduced harddisk head seek. This was particularly welcome after the battery capacity decreased. It also improved reliability because it decreased paging. Of particular note, Adobe Photoshop crashed less frequently.

For an idle system, extra memory will be an extra drain of energy. Likewise, it is an additional source of failure. However, in typical usage, it may be very beneficial.

Anyhow, if you wish to use every page of 6502/65816 RAM as cache then you should make the I/O range as small as possible. Energy for additional address decode may be less than energy for additional data transfer. However, if RAM isn't critical then you should use the flattest, coarsest address decode scheme.

You may also want to avoid 65816 unless you use the extended features heavily. At 5V, W65C02 core uses 0.5mA/MHz whereas W65C816 uses 1.0mA/MHz, which is expected, given that W65C816 has approximately double the number of transistors. There are claims that W65C816 may be three times faster than W65C02. This would be a win by transistor count and energy consumption. Superficially, it would appear to be false because the proportion of bus bandwidth allocated to operands can only double. However, with additional addressing modes and corner cases, such as summing 16 bit values (or the infamous sieve benchmark where 65816 is faster than 68000), there are cases where 65816 uses less energy. Unfortunately, there are more numerous cases where W65C02 uses less energy - and the most common case is running legacy 8 bit applications. Either way, the difference is unlikely to exceed 20mW.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!