MISC - Stack Based vs. Register Based

rickman · 2013-03-29T21:00:50+00:00

I have been working with stack based MISC designs in FPGAs for some years. All along I have been comparing my work to the work of others. These others were the conventional RISC type processors supplied by the FPGA vendors as well as the many processor designs done by individuals or groups as open source. So far my CPUs have always ranked reasonably well in terms of speed, but more importantly to me, very well in terms of size and code density. My efforts have shown it hard to improve on code density by a significant degree while simultaneously minimizing the resources used by the design. Careful selection of the instruction set can both improve code density and minimize logic used if measured together, but there is always a tradeoff. One can always be improved at the expense of the other. The last couple of days I was looking at some code I plan to use and realized that it could be a lot more efficient if I could find a way to use more parallelism inside the CPU and use fewer instructions. So I started looking at defining separate opcodes for the two primary function units in the design, the data stack and the return stack. Each has its own ALU. The data stack has a full complement of capabilities while the return stack can only add, subtract and compare. The return stack is actually intended to be an "address" processing unit. While trying to figure out how to maximize the parallel capabilities of these units, I realized that many operations were just stack manipulations. Then I read the thread about the relative "cost" of stack ops vs memory accesses and I realized these were what I needed to optimize. I needed to find a way to not use an instruction and a clock cycle for moving data around on the stack. In the thread on stack ops it was pointed out repeatedly that very often the stack operands would be optimized to register operands, meaning they wouldn't need to do the stack ops at all really. So I took a look at a register...

Mar 29, 2013 60 Replies

Rate this thread:

Rod Pemberton 13 years ago

"Albert van der Horst" wrote in message news:515e262b$0$26895$ snipped-for-privacy@dreader37.news.xs4all.nl...

Why do you say that?

It seems good for 256 byte (or less) lookup tables, 8-bit character translation, simple decompression algorithms, etc. You can even use it for multiple tables at once, e.g., using XCHG to swap BX. It's definately difficult for a compiler implementer to determine when to use such a CISC instruction.

Rod Pemberton

Vote