MISC - Stack Based vs. Register Based

[Albert van der Horst]

In article <kjtjne$nfu$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:

On 4/7/2013 5:59 PM, Brian Davis wrote:
rickman wrote:

So the main memory and stacks could be accessed for reading and writing
in the same clock cycle, read/modify/write. You can't do that with today's
block RAMs, they are totally synchronous.

I had the same problem when I first moved my XC4000 based RISC
over to the newer parts with registered Block RAM.

I ended up using opposite edge clocking, with a dual port BRAM,
to get what appears to be single cycle access on the data and
instruction ports.

As this approach uses the same clock, the constraints are painless;
but you now have half a clock for address -> BRAM setup, and half
for the BRAM data<-> core data setup. The latter can cause some
some timing issues if the core is configured with a byte lane mux
so as to support 8/16/32 bit {sign extending} loads.

Yes, that was one way to solve the problem. This other I considered was
to separate the read and write on the two ports. Then the read would be
triggered from the address that was at the input to the address
register... from the previous cycle. So the read would *always* be done
and the data presented whether you used it or not. I'm not sure how
much power this would waste, but the timing impact would be small.

I looked at making the register block RAM part of the main memory
address space. This would required a minimum of three clock cycles in a
machine cycle, read address or data from register, use address to read
or write data from/to memory and then write data to register. If it
helps timing, the memory write can be done at the same time as the
register write. I'm not crazy about this approach, but I'm considering
how useful it would be to have direct address capability of the multiple
register banks.

Some of the comments about register vs. stacks and what I have seen of
the J1 has made me think about a hybrid approach using stacks in memory,
but with offset access, so items further down in the stack can be
operands, not just TOS and NOS. This has potential for saving stack
operations. The J1 has a two bit field controlling the stack pointer, I
assume that is +1 to -2 or 1 push to 2 pop. The author claims this
provides some ability to combine Forth functions into one instruction,
but doesn't provide details. I guess the compiler code would have to be
examined to find out what combinations would be useful.

This is the approach we took with the FIETS chip, about 1980, emulated
on an Osborne CPM computer, never build. The emulation could run a Forth
and it benefited from reaching 8 deep into both the return and the data
stack. It still would be interesting to build using modern FPGA.

The compiler end is not my strong suit, but I suppose I could figure out
how to take advantage of features like this.

--

Rick

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

 

[Rod Pemberton]

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in
message news:515e262b$0$26895$e4fe514c@dreader37.news.xs4all.nl...

The existance of an XLAT instruction (to name an example)
OTOH does virtually nothing to make the life of an
assembler programmer better.

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