[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] PC management ?



hello,

nicO wrote:
> Why the PC isn't mapped inside the register bank ?
because it would become a limiting factor, a "bottleneck",
just as "flags" would be.

> Is there is specific reason ? Because cJump/cmove are really similar.
> And there is some instruction to produice hit in specific adresse.

I can think of at least one specific and good reason : the pipeline.
During the first stages (specifically fetch, decode and Xbar), there
are 3 different values of PC. Having one "logical" PC would cause
some problems. If you have no "PC" then you have no problem.
Of course, the scheduler selects the right PC value upon
IRQ or fault, and writes it to the LSU for the backup.

> Concerning the gestion of the L0. I propose to say that the alias aren't
> manage at all. BUT we must see how a c compiler could handel pointer.
> I'm really afraid that that it's almost impossible to be sure that some
> C code use to much pointer to the same area.
One has to live dangerously, or nothing gets ever done :-)
i'll try to work on a better aliasing system, which would allow up to 4 registers
to use a single L0 line. Then it should be enough for common cases.

Note that when a program is compiled, the allocation of the global
and local addresses is performed at the end, when we know the access patterns.
In an adapted compiler, we can modify the allocation rules with
a better algorithm.


HOWEVER, because the jump takes one cycle instead of none, we could change
the memory system (sorry, i call "memory system" the LSU+fetcher+TLB block)
into a 2-level LUT system, as i first envisioned it. then all the aliasing
problems are gone. the 64-entry LUT will become very difficult to manage,
however :-( [this is the reason why i developped the system as we now know it).

what do you think ?

> nicO
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/