Without a pipeline, I could use a 100kbit code read capability but to what use? If each instruction processing is required to start no earlier than after the previous instruction stopped, there would be no overlap and there would be no use to know what the following instructions are.

With a pipeline, you can add improvements such as overlapping execution, speculative execution, duplication of slow execution units, etc.

Don't know why you think you would need to be able to read all data bytes between the current position and to the longest conditional jump target. With a pipeline that have bandwidth enough to read instructions at n times higher speed than you process the instructions, and a pipeline+cache that is storing enough following instructions to take into account the number of cycles needed for one code read (reading from flash is often not a 1-cycle operation when you step up the clock frequency), then the already read instruction cache can already keep the following 2-5 instructions, while the analysis of the future instructions can identify future branches that will require speculative instruction fetching even before the processor will know if the branch will be taken or not.

In the end, the big requirement is just that the memory bandwidth (very wide, or dual/quad-pumped) is high enough in relation to the number of read cycles needed, that the processor can retrieve instruction bytes at 2, 3 or 4 times higher speed than it will consume them. It is a known fact, that a flash is slow, i.e. you can't easily reduce the cycle time. But it is at the same time a known fact that it is quite cheap to produce wider memory interfaces when accessing internal memory.

In the end, you don't have to worry about the jump distance for your conditional branches. Remember that the concept is working on processors with longer jumps (conditional and non-conditional) than the 8051 has.

What you have to worry about is the pipeline length, the quotient between code memory bandwidth and code consumption rate, in relation to code containing continuous branches after each other. A longer pipeline will quicly increase the complexity of having multiple concurrent branches to try to predict, before you reach the point when the processor knows which branch alternative that got taken. A zero-length pipeline would result in stalls, while waiting for the flash to supply data from the branch destination, or require the processor to run at so low speed that the flash can keep up, or require that all code is pre-copied to RAM, as is done in some processors.


Maybe you don't care. But maybe you should not discuss pipelined methods of speeding up a 8051 as an alternative to a pipeline.


Are you surprised if processors who do out-of-order or concurrent execution uses a pipeline, and inside this pipeline makes the decision how instructions can be swapped or combined? Doing it without a pipeline would require a quite advanced decision to be made in zero-cycle time - or require that your processor run slow enough that you could ripple through all your decisision. But instruction combining is something you do to get speed. And a pipeline is the #1 thing you look at to get speed.

After all - you have several times tried to talk about the ALU handling data two times for each instruction. One for address and one for data. But that means that the ALU has to be twice as fast. That can be rewritten: The processor must be half as fast, to let the ALU get enough time. With a pipeline and the individual jobs separated, you would stream the data through the processor, and the ALU would not have to reserve any time for any addresses. This means that a specific process technology, with a specific gate propagation time, would allow a faster processor. In a streamed design, each block is normally simpler, so the hardware for handling the address calculations don't need to support any multiply. For better processors, it will on the other hand support n-step shifts, allowing you to do array accesses of 2^n-sized entries with a[idx], a[2*idx], a[4*idx]. Small, specialized, blocks can do a better job.

In the end, I do not believe that the DP8051 is odd for using pipelining. It is far more likely that most of them are using pipelining. The alternative is of course to take a 4-clock core. Add an internal clock multiplier running the core at 100MHz with a 25MHz external clock and call it a 25MHz 1-clocker. The little problem with this choice is the timing of external memory - people may be a bit surprised when the 100MHz internal speed shows through - unless the manufacturer says that external memory accesses will take extra time, and adds clock stretching.


You are either talking about a pipeline, but refusing to call it a pipeline, or you are talking about a standard cache. The cache have bits telling about valid or free slots.


A pipeline is something you can use for many things. You seem to have focused on a single specific use for the pipeline. With the high latencies of flash memory, the ability to predict required code bytes should not be ignored. The ability to decode an instruction while saving the result of the previous instruction should not be ignored either. But there are many more things to a pipeline, so don't limit yourself to the piepline descriptions you might have found in early microprocessor documentation.

A 12MHz 12-clocker that needs 12 extra clocks will introduce 1us extra interrupt latency.
A 100MHz 1-clocker that runs the instructions with a one-clock stagger would always add 10ns extra interrupt latency from that extra pipeline step.

A pipeline is something you use to get brutal speeds out of a specific process, by adding opportunities for concurrency in all stages of the processor. You can produce a pipeline that has predictable execution times. The ability of increasing the clock frequency can allow the interrupt latency to shrink despite extra cycles in the pipeline. And the next thing is that the interrupt latency is actually two factors. One factor is time to first ISR instruction. The other factor is time until interrupt fully serviced - your ISR may have to look at flags, pick up data etc. In the end, you shouldn't bank too much on the "I would hope to avoid that". Especially since it isn't so very unlikely that you are currently using a pipelined processor, and loving it.


It's absolutely impossible to know what you care about, since it seems to be absolutely impossible to guess what your responses will be to any comment.


Not sure what subject you are debating now. I thought we where debating latencies. A 8-bit processor does less work with each instruction than a 32-bitter, so latencies are evey more important to keep an eye on.


Wonderful view. You are probably the only one in this world with that view. I think you should be carefull with publishing it - at what time do you think your customers will go for another supplier?

My customers don't spend too much time expecting me to be faithful to a specific processor architecture, or that the selected processor must allow the full addressable memory range to be used. They only focus on a well-working product at a reasonable price. That is the reason why every new project includes a quite broad analysis of the availability of processors. That is also the reason why our products sometimes do jump between architectures. An 8051 may become a PIC. A PIC may become an AVR. An AVR may become an ARM. A PPC may become...