[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] F-CPU fetch unit



hi, sorry for the delay, there were some crazy days at work...

--- Yann Guidon <whygee@xxxxxxxxx> wrote:

> Jumps(as well as call, return etc.) is a bit weird when compared to 
> other architectures.
> The goal was 1) to escape current patents 2) to remove unnecessary 
> operations 3) to exploit
> as much as possible a certain set of seemingly unrelated units to get 
> the most out of them.
> 
> To start with the developper's eye, there is no "jump +100" or so (as 
> seen in x86 and others).
> The reason : computing the jump address, checking the TLB, and so on, 
> are VERY slow.
> So the slowness is spread among several operations : one "prepares" the 
> jump, and the other
> actuall performs it (this also reduces the need for delay slots).
> 
> The best code examples are found in the call/return and loop situations,
> where we have a perfect locality to exploit. The jump addresses are stored
> in a normal register (that is the VIRTUAL one, when in user mode, so that
> the REAL state of the computer can be saved transparently whenever
> a task switch occurs) as well as in the Fetcher (the linear address).
> Return and loop are specific kinds of jump
> because there is almost nothing to do : the Fetcher already contains
> the target instructions. We just have to instruct it to keep the data
> for a while, so there is no penalty when reusing the instructions.
> This is done with the "call" and "loopentry" instructions :
> they mark the "current line" in the fetcher as "do not flush"
> In case there is a flush or a task switch, the data are not lost,
> the jump address is kept in the register set.
> 
> For a "normal jump", there is also a prefetch instruction,
> that loads the current PC, adds a register and an immediate,
> and stores the result to another register. A side effect is that
> the result is checked in the TLB and the target register
> is "associated" to a given line of the Fetcher, which starts
> a memory fetch if it is absent.
> This way, the jump or call instructions do have one cycle
> of penalty in the best case (this is not compressible). In the
> worst case (which i think will be quite common), this might
> take maybe ten cycles. So scheduling is very important,
> but not as difficult as on x86 because every architectural
> detail is exposed.
> 
> Note that the LSU (that is : load and store)
> works mostly the same, with the added complexity of
> supporting reads and writes (so there are a bit more ports)
> with any bit width. There, latency is hidden because
> we can perform both read/write in parallel with pointer update.
> 

ok, so let's see if I got this straight.
The fetcher has N_LINES independent lines. The PC is output from the fetcher and it represents the
virtual (or physical) address of the currently delivered instruction. Each one of the lines can
get an instruction from the cache based on the page address returned by the TLB and the internal
counter from each line. Any loop, call, or jump is marked in the responsible line and that line
should keep the specific physical addres for a while. The line is flushed after a timeout or is
there a specific instruction for that?
Also it seems that there is a need to sometimes instruct the fetcher to begin fetchig from an
address that is in the register set. Is this right so far?

> The Fetcher does not replace entries in the TLB.
> It fills the cache and its lines with data that belong to the current 
> process,
> as indicated in the TLB.

yes, and the TLB is controlled by the OS. So basically the fetcher only has a red interface to the
TLB?

> 
> The "execution units" (in the "execution pipeline") are quite 
> straightforward to design,
> they have an obvious interface (data in and out, plus all the necessary 
> flags) and they
> can stand alone. However, as you see, the rest is not easy at all, 
> because of their interactions
> and collective work.
> 
> But the execution units are not all finished.
> 

hey, somebody's got to start the hard part eventually :)


--------------------------------
I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the fear has gone there will be nothing.
Only I will remain.
--------------------------------


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/