Re: delayed branches and zero overhead loops

[Joern Rennecke <joernr at arc dot com>]

On Wed, Feb 14, 2007 at 10:29:45AM -0800, Doug Evans wrote:
> Joern Rennecke writes:
> 
>  > If you wanted to generate a gcc machine description, than this is
>  > in principle relevant - except that expressing this all in generic rtl
>  > would likely lead the machine description generator to give up,
>  > since it won't be able to find any basic arithmetic instructions -
>  > every instruction will be flagged as having conditional flow control.
> 
> I wouldn't add this specification to the insns.  Blech.
> I would add it to the same place where "condition" and "setup-semantics" is.

Yes, that's a reasonable place to put the specification for the semantics
when you are executing one insn at a time.  Still, there should also
be a way to streamline this with the pbb simulator.
Note that trying to do this fully automatic would require a combination of
profiling and artificial intelligence; you need to realize that, although
loop_end can be changed at runtime, it is not likely to change all too often,
so it makese sense to to the comparison at decode time, and invalidate
any decoded pbb if a new loop end is placed inside it.

FWIW, the condition part of the isa form is actually not usable for ARC,
since not all instruction take the canonical condition.
lpcc takes it, but it has a no-noop 'else' operation.  A number of
instructions take a different condition, or none at all.

> No claim is made that new fields that are reasonable can't be added here.
> 
>  > > Having said that, I can imagine partitioning the description file
>  > > into multiple files such that these pseudo-insns are only seen by
>  > > the application in question.
>  > 
>  > Why does it have to be yet another file?  There is already a syntax-only
>  > attribute that specifies that some information is only for applications that
>  > care about syntax.
>  > Not that I am fundamentally opposed to doing it with separate files,
>  > but it appears to me that it makes things core complicated rather than
>  > simpler.
> 
> There's no basic limit on the number of applications that can use cgen.
> I would argue against a modus operandi that had the default behaviour
> of adding such (obvious) application specific stuff to the basic
> cpu description file.  When working with libraries, programmers don't
> think of modifying the library in their first pass at using it.
> Same reasoning applies here.

Then we'd need some mechanism to allow sem*switch.c to be built using
application-specific fragments, so that the required pseudo instruction
can be included in the switch.

Would you also want to re-design the way the sh.cpu deals with the different
delay slot mechanisms of sim and sid?
It seems rather strange that delay slots have to be described in two
languages at once.