Log#35 : Register Parking

A project log for YASEP News archives

A backup of the blog before the host erases it. A good opportunity to review the development, twists and turns of this ISA !

Yann Guidon / YGDESYann Guidon / YGDES 04/09/2020 at 10:080 Comments

By whygee on Tuesday 8 November 2011, 16:29 - Architecture

Warning : this is partially deprecated since 2013-08-09, see!doc/reg-mem#parking

As the YASEP architecture specifies, there are 5 normal registers (R1-R5) and 5 pairs of data/address registers (A1-D1, A2-D2...) and it's quite difficult to find the right balance between both : each application and approach requires a different optimal number of registers.

When more registers are needed (if you need R6 or R7) then you could assign them to D1 and D2 for example. However you have to set A1 and A2 to a safe location otherwise chaos could propagate in the software. Another issue is that each write to the A registers will update the memory. A similar situation appears if we use the Ax registers as normal registers : each write will trigger a memory read. And in paged/protected memory systems, this would kill the TLB...

This is now "solved" with today's system, which defines hardwired "parking" addresses and internal behaviour (this is still preliminary but looking promising).

In the end, it's not very complex (not as much as it seems). The hardware price is a few logic gates that detect the parking addresses to inhibit memory writes. For the software writer, it just means more registers on demand and it will work whether the YASEP has the parking hardware or not. You CAN have R6, R7 or R8 but then you'll have to restrict data access and give up A1/D1, A2/D2 and A3/D3. You make the choice !


Parking was later modified and simplified. All the registers are parked at address #-1.
There must be a clever trick to implement it implicitly with a compiler... Register allocation is a key ;-)

Now I imagine that the data register writeback to memory should be triggered only when the address is changed... So a temporary data lifetime starts when the address is changed : this "flushes" the previous data in the register, "allocates" a new location and it's written/committed to memory when a new address is given. This moves the aliasing problem to somewhere else (due to simultaneous access by different pairs) but it's still worth investigating !

One thing is certain, though : new methods must be invented from scratch.