From: lkcl <lkcl@web>
Date: Sat, 9 Oct 2021 12:10:00 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~3678
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e31b76e73c95911a65a241e6ba6fb25a7fc55251;p=libreriscv.git

---

diff --git a/3d_gpu/architecture/dynamic_simd/shape.mdwn b/3d_gpu/architecture/dynamic_simd/shape.mdwn
index 1fd1350f6..6cb0259ed 100644
--- a/3d_gpu/architecture/dynamic_simd/shape.mdwn
+++ b/3d_gpu/architecture/dynamic_simd/shape.mdwn
@@ -43,7 +43,7 @@ widths.
 A minor wrinkle which emerges from deep analysis is that the overall
 available width (`Shape.width`) does in fact need to be explicitly
 declared, and
-the sub-partitions fit onto power-of-two boundaries, in order to allow
+the sub-partitions to fit onto power-of-two boundaries, in order to allow
 straight wire-connections rather than allow the SimdSignal to be
 arbitrary-sized (compact).  Although on shallow inspection this
 initially would seem to imply that it would result in large unused
@@ -87,3 +87,19 @@ These facts also need to be communicated to both the SimdSignal
 as well as the submodules implementing its core functionality:
 add operation and other arithmetic behaviour, as well as
 [[dynamic_simd/cat]] and others.
+
+In addition to that, there is a "convenience" that emerged
+from technical discussions as desirable
+to have, which is that it should be possible to perform
+rudimentary arithmetic operations *on a SimdShape* which preserves
+or adapts the Partition context, where the arithmetic operations
+occur on `Shape.width`.
+
+    >>> XLEN = SimdShape(64, signed=True, ...)
+    >>> x2 = XLEN // 2
+    >>> print(x2.width)
+    32
+    >>> print(x2.signed)
+    True
+
+