From: lkcl Date: Sun, 22 Nov 2020 14:16:56 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1692 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=c6314cac40b17270ac7682481aa80960b960dd24;p=libreriscv.git --- diff --git a/openpower/sv/toc_data_pointer.mdwn b/openpower/sv/toc_data_pointer.mdwn index 4d04e7966..3342754cb 100644 --- a/openpower/sv/toc_data_pointer.mdwn +++ b/openpower/sv/toc_data_pointer.mdwn @@ -4,4 +4,15 @@ See 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,