From c6314cac40b17270ac7682481aa80960b960dd24 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 22 Nov 2020 14:16:56 +0000 Subject: [PATCH] --- openpower/sv/toc_data_pointer.mdwn | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) 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, -- 2.30.2