Re: delayed branches and zero overhead loops

[Doug Evans <dje at transmeta dot com>]

Joern Rennecke writes:
 > On Tue, Feb 13, 2007 at 11:24:53AM -0800, Doug Evans wrote:
 > > It sounds like you want to add an application specific entry to the
 > > cpu description file.  For me that's an ipso-facto wrong way to go.
 > 
 > This is something only of concern to applications that care about the
 > semantics of the insns.  Thus, gas does not need to know about this.

Clearly. [And the chosen implementation is specific to the
particular simulator you're writing.]

 > 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.
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.

Having said that, I can envision providing the necessary specification
along side setup-semantics, and then having the simulator make use of it.
If done this way, the specification is of the architecture in a (hopefully)
reasonably useful way and any app that wants to make use of the data can.

 > If you want it to frame it in terms that give universal meaning to the
 > instruction semantics, you can express it in three pieces:
 > - A piece of rtl that might need to be appeded to the semantics of 
 >   every instruction.
 > - A condition that tests if this piece of rtl should actually be
 >   executed, for use in a simple interpreter.
 > - In the mloop.in:xextract-pbb code, code that computes at decode time
 >   when to append the pseudo insn to a pbb
 >   (or if you have some other use for a pseudo insn that doesn't end
 >    a pbb, you might also stick it into the middle).

Right, setting aside the last part.  I'm not sure I'd do it that way,
but I haven't been in that particular code for awhile.

 > > Thus question: Is there a way to express the zero-overhead
 > > loops in an a way that is more faithful to being just a
 > > description of the architecture, and not an application specific hack.
 > 
 > As I said above, you can do it by adding rtl to every instruction that makes
 > every instruction COND_CTI.

And (I think) we both agree this isn't the best way to go.

 > > Which leads to me next question:
 > > Is ARCompact a variant of the ARC for which I did a port ages ago?
 > 
 > Unfortunately, the sourceware.org cvs history is a bit patchy - e.g. the
 > bfd cvs history only goes back to 1999 - so I'm not sure which part(s)
 > of the toolchain you ported, and to what ARC variant.

lp_start, lp_end, lp_count sound very familiar,
as does special casing of r62.