delayed branches and zero overhead loops

[Doug Evans <dje at transmeta dot com>]

Joern Rennecke writes:
 > Like for delay slots, this pseudo instruction will need and extra decoded
 > insn slot, so again it is important to know if it is allowed to use one extra
 > slot.
 > A further problem is that I don't want to have a nonsense encoding for
 > the pseudo insn which could be triggered by invalid code, and/or cause decoder
 > conflicts.  Hence, there should be a way to define instruction semantics
 > without an instruction encoding.
 > What do you think would the bets way to express this?
 > No format field?  Treating an empty format field in a special way?
 > Adding a magic attribute that causes the format field (or its absence) to
 > be ignored?

fwiw,

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.

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.

And then having said that, the degrees of freedom for how to
implement this are much more open.

If I were to choose from the options you suggest, and I'm not sure
I would, but if I were, I'd go with something explicit.
The absence of something shouldn't denote special behaviour.
What if a later developer forgets to add something?
Did he really forget, or is he trying to denote this special behaviour?
Thus of the choices mentioned, an attribute is the preferable one.

fwiw, I think the partitioning of problems into application
independent and application dependent parts is fundamental to cgen.
Clearly zero overhead loops are part of the architecture, but
as I understand the plan of attack, it sounds like you're going
for an application specific solution - what if a different
simulator wants to do things differently?
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.

Which leads to me next question:
Is ARCompact a variant of the ARC for which I did a port ages ago?
[I didn't do a simulator port for it though, I had to use the one given me.]
I forget if/how it handled zero overhead loops.
Can you refresh my memory?  That might help in coming up with
a reasonable solution.