From: lkcl Date: Sun, 13 Dec 2020 02:51:13 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1356 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9175fe8281f86461d881a3203be8f0ef608c89d2;p=libreriscv.git --- diff --git a/openpower/sv/svp_rewrite/svp64/discussion.mdwn b/openpower/sv/svp_rewrite/svp64/discussion.mdwn index 97a29022e..045a1e8dd 100644 --- a/openpower/sv/svp_rewrite/svp64/discussion.mdwn +++ b/openpower/sv/svp_rewrite/svp64/discussion.mdwn @@ -145,7 +145,7 @@ Some thoughts on this: the sensible (sane) number of CRs to have is 64. A case How to number them as vectors gets particularly interesting. A case could be made for treating the 64 CRs as a square, and using CR numbering (CR0-7) to begin VL for-loop incrementing first by row and when rolling over to increment the column. CR6 CR14 ... CR62 then CR7 CR15 ... -When the SV prefix marks them with 2 bits, one of those could be used to indicate scalar, and the other to indicate whether the 3 bit CR number is to be treated as a horizontal vector (CR incrementing srraight by 1) or a vertical vector (incrementing by 8) +When the SV prefix marks them with 2 bits, one of those could be used to indicate scalar, and the other to indicate whether the 3 bit CR number is to be treated as a horizontal vector (CR incrementing straight by 1) or a vertical vector (incrementing by 8) When there are 3 bits it would be possible to indicate whether to begin from a position offset by 4 (middle of matrix, edge of matrix).