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

Re: [f-cpu] new cjump instruction



This is not a problem regarding only compiler. It also is a problem
regarding link editor (aka "ld" in Linux) :

We have a collection of functions scattered in several object files, those
functions would need to be aligned in a page boundary, which means a lot of
holes when merging them because the size of a function code is hardly of a
page size. Just imagine the case where the codes of both funtions exceed a
page size so that the second code has a cjump instruction outside the first
page, you get a bug because this cjump would jump somewhere in the second
page instead of the first page whereas it should jump to a label located in
the first page. Even the linker would be unable to fix it without placing
all the second code in the second page so the cjump works well. Such a
behavior is very bad because at the end your final executable would be
larger than necessary, takes too many pages and causes too many TLB misses.

By the way, the compiler must be as simple as possible. If the compiler is
able to rearrange the code, you still can find the same problem  about holes
between function codes (you just shift the problem in fact).

So I think this idea is not wishable and not viable (TLB caching pressure
increases because of holes).


----- Original Message -----
From: "nico" <nico@seul.org>
To: <f-cpu@seul.org>
Sent: Saturday, April 12, 2003 6:22 PM
Subject: Re: [f-cpu] new cjump instruction


> On Sat, 12 Apr 2003 02:54:07 +0200
> Yann Guidon <whygee@f-cpu.org> wrote:
>
> > hi all,
> >
> > nico wrote:
> >
> > >On Fri, 11 Apr 2003 11:16:04 -0600
> > >ben franchuk <bfranchuk@jetnet.ab.ca> wrote:
> > >
> > >>nico wrote:
> > >>
> > >>
> > >>>I propose a new cjump to enable 0 cost jump.
> > >>>
> > >>>cjump (R1,#imm12, cond)
> > >>>{
> > >>>if (cond(R1))
> > >>>{
> > >>> PC = (PC & 0x0FFF) | #imm12;
> > >>>}
> > >>>else
> > >>>{
> > >>> PC++;
> > >>>}
> > >>>
> > >>>}
> > >>>
> > >>>PC lsb is just replaced by the 12 bit constant, that's lightning
> > >>>fast. No cycle could be lost by reading register bank.
> > >>>
> > >>>What do you think of it ?
> > >>>
> > >>>
> > >>Try using it with real code and you will see the problem.
> > >>hint: page boundry is random.:(
> > >>
> > >>
> > >
> > >??
> > >That's a compiler problem. So ?
> > >
> > >
> > huh, i don't think that it's a good answer ....
> >
> > on top of that, this technique poses new problems in FC0's pipeline.
> > sure, addresses are computed fast, but what about their validation,
> > their fetch, their lookup in the buffers ......
>
> Validation are usefull because you are inside a pages.
>
> fetch are ligthening fast. You have an entire clock cycle to do it (no
> adder or register read before accessing L1 caches).
>
> But the real problem is for the compiler. What is the opinion of the
> compiler writter ?
>
> nicO
>
> >
> > >>Ben.
> > >>
> > >>
> > YG
> >
> > *************************************************************
> > To unsubscribe, send an e-mail to majordomo@seul.org with
> > unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

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