important to update about tax agreements
[crowdsupply.git] / updates / 005_2018dec14_simd_without_simd.mdwn
index b33158fa628860ca19d9cd75a619118a6aeb6852..b003637244f0a36dcfa1b1267479a6d2975ceceb 100644 (file)
@@ -2,17 +2,17 @@ Spread over various [videos](https://youtu.be/DoZrGJIltgU),
 [writings](https://groups.google.com/forum/#!topic/comp.arch/2kYGFU4ppow),
 and [mailing list
 discussions](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2018-December/000261.html),
-a picture is beginning to emerge of a suibable microarchitecture.
+a picture is beginning to emerge of a suitable microarchitecture.
 
 There are several things to remember about this design, the primary
 being that it is not explicitly intended as a discrete GPU (although
 one could be made). Instead, it is primarily for a battery-operated,
 power-efficient hand-held device, where it happens to just about pass
-on, say, a low to mid-range chromebook.  Power consumption *for the
-entire chip* is targetted at 2.5 watts.
+on, say, a low to mid-range Chromebook.  Power consumption *for the
+entire chip* is targeted at 2.5 watts.
 
 We learned quite quickly that, paradoxically, even a mobile embedded
-3D GPU *requires* extreme an number of registers (128 floating-point
+3D GPU *requires* an extreme number of registers (128 floating-point
 registers) because it is handling vectors (or quads as they are
 called), and even pixel data, in floating-point format, which means
 four 32-bit numbers (including the transparency).  So, where a
@@ -26,7 +26,7 @@ Dealing with 128 registers brings some unique challenges not normally
 faced by general purpose CPUs, and when it becomes possible (or a
 requirement) to access even down to the byte level of those 64-bit
 registers as "elements" in a vector operation, it is even more
-challenging.  Recall Mitch Alsup's scoreboard dependency floorplan
+challenging.  Recall Mitch Alsup's scoreboard dependency floor plan
 (reproduced with kind permission, here):
 
 {mitch-ld-st-augmentation | link}