[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1056

--- Comment #4 from paulus at ozlabs.org ---
Overall my main comment would be that this doesn't read like an architecture
specification; rather it reads more like a journal article. It needs to state
precisely and concisely and completely how the system operates. It doesn't need
to argue for it or against other systems.

Title: "SVP64 Zero-Overhead Loop Prefix Subsystem" seems fine to me.

The RFC needs to be based on v3.1B rather than v3.0B (particularly since it
depends on prefixed instructions).

Introduction section:

1st paragraph: The comparison with Z80 or 8086 instructions isn't appropriate
or helpful. If you really want to do that then we need to have a references to
bibliography entries that reference specific Z80 or 8086 architecture
documents. In any case what you are doing here is far beyond anything that Z80
or 8086 ever did, so pointing to the descriptions of those instructions doesn't
get us very far. Also, many (most?) readers will never have used a Z80 or 8086,
so the reference is not illuminating.

In the last sentence you introduce a way of viewing this stuff only to then say
that that isn't a good way to view it. So why introduce it at all?

The first paragraph just needs to say that this system is based on the idea of
repeatedly executing a specific scalar instruction across a series of
registers. Be specific and factual about what Simple-V does.

2nd paragraph: It is unacceptable in my opinion to use such a completely
different convention here from the rest of the ISA. It can only cause massive
confusion.

3rd paragraph: "Defined word" is not a concept in the architecture. "Defined
word instruction" is, but that is to be parsed as (defined (word instruction))
not ((defined word) instruction).

In this and subsequent paragraphs, you keep hammering on the idea that the
underlying scalar instruction is (a) a word instruction and (b) completely
unchanged in its behaviour. Neither is in fact true. As to the unchanged
behaviour, it is not clear why that would be so crucially important even if it
were true.

Instead it would be far more helpful to put a complete list of the ways that
the behaviour of the underlying instruction is (or can be) changed. (Note that
such a list would then automatically prohibit any other behaviour changes.) The
list would include changes to source and destination register numbers,
bit-width of operation, suppression of operation (due to predication), writing
a zero result (due to predication), arithmetic saturation, whatever "vectorised
branch-conditional" is, and whatever else Simple-V allows that I have missed.
Forward cross-references would probably be helpful here.

4th paragraph: the word "apparent" trips me up, because it leads me to expect
that you will explain why these are not in fact real exceptions, but you don't,
and in fact seem to end up saying that they are real exceptions (but that's
good). Also, if you intend to remove post-increment, then just remove it for
now and add it back later if you change your mind.

5th paragraph: You really can't prohibit future architects from doing anything.
If nothing else, they could just remove this paragraph. At most you can say
that doing certain things in future is likely to cause difficulties for
implementators of future versions of the architecture. (You can't really even
be sure about that, because future implementers might invent amazing new
implementation techniques that would easily overcome any difficulty you
propose.)

This paragraph is a bit like Parliament passing a law saying that Parliament
may not in future pass a law allowing a particular thing. It's futile and
ineffective.

6th paragraph: Mention of subset implementations is good. I have some
reservations about overloading the term "Compilancy Subsets" since that already
has another meaning, and to use it for two different things could be confusing.

I think it would be helpful here to mention briefly at least that the number of
GPRs, FPRs and CRs gets increased in some of the levels of Simple-V.

To be continued...

-- 
You are receiving this mail because:
You are on the CC list for the bug.