[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 #9 from paulus at ozlabs.org ---
"Register files, elements, and Element-width Overrides" section:

I strongly disagree that the register file should be accessed in little-endian
byte order when the processor is in big-endian mode. Requiring that will make
Simple-V practically unusable in big-endian mode (just as saying that the
register file has to be big-endian always would make Simple-V unusable in
little-endian mode).

Instead the register file should be accessed in the endian mode of the
processor, because that means that the relationship between array indices in
memory and element numbers in the register file is the identity mapping (or at
worst just the addition of a constant), regardless of endian mode, assuming
that ordinary ld/std (or lfd/stfd) instructions are used to transfer data
between registers and memory.

Elements are not unbounded arrays - there are only a finite number of them that
exist. You don't specify what happens if you run off the end of the register
file. The architecture needs to specify that.

The third dot point is not clearly expressed. I think it means that
element-width overrides cause the register file to be considered as an linear
array of chunks of that width (but the register number specified in the
instruction is still interpreted in 64-bit units, right?).

2nd & 3rd paragraphs: in ANSI C, are you sure that indexing beyond the bounds
of a union is defined behaviour? I'm not, and if it isn't, then ANSI C isn't
the best language to use here.

The sentence about VSX along with the "Future specification note" don't add
anything useful, so drop them. Also, "bounded fixed" sounds awkward.

5th paragraph: As I said, I think this is entirely the wrong choice.

6th paragraph: I think that by "Arithmetic and Logical" you really mean
"Fixed-Point" (as opposed to Floating-Point or Branch). There are
floating-point Arithmetic instructions.

6th & 7th paragraphs: Once again you are hammering the point that the
instruction is not altered, but it is not clear why you need to belabour this.

Is it possible to request saturating arithmetic with the SVP64 prefix on an
addi instruction? If so then that would certainly count as a fundamental change
to the operation being performed.

In fact I think that changing the element width is a fundamental change. But
that's fine - the important thing is that the changes to the instruction's
operation are precisely and fully defined. Saying "nothing is changed" is
obviously not precise or complete, some things are changed (e.g. element
width). Saying "nothing fundamental is changed" doesn't help either, because
there is no definition of "fundamental".

8th paragraph (starting "Element offset numbering"): I have no idea what
"LSB0-sequentially-incrementing" means as opposed to "MSB0-incrementing". You
seem to be projecting your confusion and lack of comprehension of big-endian
bit numbering onto the reader here. (Note that I agree that little-endian bit
numbering is generally easier to use than big-endian bit numbering. But
big-endian bit numbering is a perfectly well-defined and self-consistent
convention.)

9th paragraph: This is all written from the perspective of someone who only
understands little-endian memory addressing. There are people, including much
of the audience for this ISA, who are very used to big-endian bit and byte
ordering and find it more natural and understandable than little-endian.

Trying to use a different convention in this part of the ISA from all of the
rest of it risks unending confusion unless it is very carefully handled. It
should be possible to define the element addressing in one place and then just
use element addresses from then on. The element addressing function should
hopefully be the only place where bit numbers need to appear.

10th paragraph: why is the similarity to the VSX definition important?

This section seems to be using a lot of words to try to express the idea that
the set of elements operated on by the iterations of a SVP64 instruction might
span several GPRs and FPRs. I think this is all made more difficult by the fact
that we haven't yet really been told how the iterations work, or even given
much idea of how many iterations there might be.

Page 5: now we've switched to python syntax, and we have this new term "VL"
that we have no idea about, since you haven't yet talked about it. Is it
absolutely necessary to use a new syntax here instead of expressing the loop
the way loops are expressed in RTL elsewhere in the ISA?

page 5, 3rd paragraph: you don't need to say "deliberate and intentional" in
bold as if that was somehow surprising. Hopefully everything in the ISA is
deliberate and intentional. This whole paragraph seems to be a reiteration of
what has been previously defined (and if it isn't then the previous definitions
should be improved).

The point about not modifying parts of a register that don't hold an element
that is part of the iteration is important, and I think the only new point
here.

The rest of the material including the table showing the effect of the example
is explanatory rather than normative, and as such should go in a Programming
Note rather than the main text.

to be continued...

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