(no commit message)

diff --git a/openpower/sv/toc_data_pointer.mdwn b/openpower/sv/toc_data_pointer.mdwn
index 4d04e7966f1c59896e4811118284a65683469e94..3342754cb4abf7af818708ac3328a467deeb97fb 100644 (file)
--- a/openpower/sv/toc_data_pointer.mdwn
+++ b/openpower/sv/toc_data_pointer.mdwn
@@ -4,4 +4,15 @@ See <https://bugs.libre-soc.org/show_bug.cgi?id=286>
 
 The concept and convention of a Table of Contents in RISC is a common one, to deal with the fsct that immediates range is short and very inefficient to get a 64 bit immediate (6 instructions in v3.0B). The TOC allows a short-range immediate to access full 64 bit data via LDs.
 
-However with a huge percentage of typical instructions being TOC style LDs (typically 6%) it makes them a high priority target for reducing executable size and I-Cache pressure.  What if there were a way to indicate that a given use of an immediate, in any instruction, was to be a micro-coded implicit TOC Load?
+However with a huge percentage of typical instructions being TOC style LDs (typically 6%) it makes them a high priority target for reducing executable size and I-Cache pressure.  What if there were a way to indicate that a given use of an immediate, in any instruction, was to be a micro-coded implicit TOC Load? Typical code:
+
+    addi  r2, r2, TOC.lopart
+    addis r9, TOC.highpart(r2)
+    ld r10, imm(r9) # getting the TOC, still not done yet!
+    lwz r9, 4(r10) # finally get actual data 4 bytes into array
+
+The first three instructions are setup to establish the desired address with the start of the dara structure.  What if, instead, the immediate indicated (through a special encoding, taking up some small part of its range) that those three previous instructions were implicit and micro-coded?
+
+    lwz r9, {TOC+4}(r0)
+
+Behind the scenes,