Re: delayed branches and zero overhead loops

[Joern Rennecke <joernr@arc.com>]

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

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

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

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

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

ARCompact is the instruction set architecture used by the ARCtangent-A5,
ARC 600 and ARC 700 cores.  It has 16 and 32 bit opcodes.
The ARCtangent-A4 had only 32 bit opcodes, but I have been told that
for user code, ARCcompact is mostly backwards ompatible to ARCtangent-A4
code.

> I forget if/how it handled zero overhead loops.
> Can you refresh my memory?  That might help in coming up with
> a reasonable solution.

The loop counter register lp_count is a core register, which
means you can do with it most of the things you can do with a general
purpose register.

lp_start and lp_end are auxilary registers, which are usually set
up with the lp / lpcc instruction althou they can also be read
and written to with the lr and sr (load / store auxilary register)
instructions.

The lp instruction set lp_start to the sucessor instruction,
and lp_end to the instruction specified by the offset embedded in the
isntruction.
likewise for lpcc if the condition is true.  If the condition is false,
lpcc will instead jump to the loop end (that is the same address that
would otherwise be laoded int lp_end).

lp_end points to the first instruction after the loop.

When the program counter is incremented to match lp_end,
lp_count is decremented; if lp_count was not 1 (i.e. it is not
decremented to zero), a jump to lp_start is performed.

The ARC 700 also as a loop inhibit bit in its status register that
gets set on interrupt, and cleared by the lp / lpcc instruction.