From 36d2df0dc6ae135afdbaca4f9f0aaa658a3dbf9d Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 29 Oct 2021 12:12:03 +0100 Subject: [PATCH] --- 3d_gpu/architecture/dynamic_simd/shape.mdwn | 22 +++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/3d_gpu/architecture/dynamic_simd/shape.mdwn b/3d_gpu/architecture/dynamic_simd/shape.mdwn index 2c834f752..86a33b6db 100644 --- a/3d_gpu/architecture/dynamic_simd/shape.mdwn +++ b/3d_gpu/architecture/dynamic_simd/shape.mdwn @@ -463,11 +463,17 @@ Summary: - Exactly the same as for when RHS is an Integer, given that the integer fixed width is, in fact, an integer. - the return result is always a fixed-width priority SimdShape -* **Either LHS or RHS Elwidth Priority** - - It is unsafe (not possible) to respect the fixed width therefore - it is always ignored - - all operators always expected to work (caveat: by only using - the elwidths) - - all operators work because they match elwidth-for-elwidth - in their computations. - - the return result is always an elwidth-priority SimdShape +* **Either LHS or RHS Elwidth Priority** (but not both) + - all operators always expected to work because, again, one of + RHS or LHS is an integer, and that integer is used as the + input to the arithmetic. + - reverse-operators (rmul etc) take care of RHS. + - the return result is however always an elwidth-priority SimdShape +* **Both LHS and RHS Elwidth priority** + - for mul and shift-left, as long as one of LHS or RHS has identical + elwidths, by a mathematical coincidence these are + fine. return result may be a dual-priority result. + - for add and sub, an exception must be raised. + - divide and shift-right are expected to work on the condition + that, again, all elwidths have the exact same value, and, again, + that no LSBs are lost. -- 2.30.2