[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 #5 from paulus at ozlabs.org ---
"SVP64 encoding features" section:

This is bewildering, because you plunge into details which are unexplained at
this point, and the reader hasn't yet even been told that all SVP64
instructions are prefixed instructions or that bits in the prefix control
various aspects of the iteration of the underlying instruction. So what are the
"only 24 bits"?

Also, saying "need to be" implies that we are still at the design stage. But
we're not; this document should be written for the situation where SVP64 is
defined, known and accepted, and people just need to know exactly what it is.

Using the word "features" in the section heading seems to imply that you are
still trying to sell people on the concept. Assume that they are already sold
and now need to know the precise details of what it is. I suggest the section
heading should be "SVP64 instruction encoding" instead.

At this point, what readers need to understand is the following:

* SVP64 instructions are always prefixed (64 bit) instructions.
* The prefix word controls various aspects of the vectorisation, and is defined
below in this section.
* The suffix word is either a defined word instruction, or is the suffix of an
instruction that has a PO9 scalar prefix (we may need a better term than "PO9
scalar prefix"). The two cases are distinguished by a bit in the SVP64 prefix
(see below).
* 64-bit instructions other than those with a PO9 scalar prefix cannot be
vectorised by SVP64.

Then there needs to be an explanation of the role of bits 6 and 7 in the SVP64
prefix, perhaps with a diagram. There needs to be an explanation somewhere else
of the PO9 scalar prefix (perhaps in Book I Chapter 1), which you need to write
and either include in this RFC or in a new RFC. You would then cross-reference
to that description.

Then you can state that in order to fit the vectorisation parameters into bits
8 - 31 of the SVP64 prefix, several different formats are defined. Include a
cross-reference to where those formats are defined, and indicate which bits of
the prefix indicate which format is being used. Ideally you would give a table
listing all of the defined formats and the bit values in the prefix that
indicate each format.

The list of features you give is really more a list of vectorisation features.
I suggest that such a list would be better in the Introduction, and should be a
complete list with cross-references to where those features are defined.

This is probably the place also to specify that the suffix word cannot be an
unvectoriseable word instruction (in the case where the prefix indicates that
the suffix is a defined word instruction), define which instructions are
considered unvectoriseable, and state that the consequence of attempting to
execute an unvectoriseable instruction with a SVP64 prefix is a Hypervisor
Emulation Assistance Interrupt (not Illegal Instruction Trap, which doesn't
exist in the architecture).

By the way, I expect that we will need to convert to American "vectorize"
rather than "vectorise". (On the general subject of -ise vs. -ize endings, the
original edition of Fowler's Dictionary of Modern English Usage says "Most
English printers follow the French practice of changing -ize to -ise; but the
OED of the Oxford University Press, the Encyclopaedia Britannica of the
Cambridge University Press, The Times, & American usage, in all of which -ize
is the accepted form, carry authority enough to outweigh superior numbers.")

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