From 57398591b40ccf7cf3d9995b2c199f541f263df7 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 9 Jun 2023 12:13:15 +0100 Subject: [PATCH] --- openpower/sv/po9_encoding/discussion.mdwn | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/openpower/sv/po9_encoding/discussion.mdwn b/openpower/sv/po9_encoding/discussion.mdwn index d85bdebc0..db1db31a3 100644 --- a/openpower/sv/po9_encoding/discussion.mdwn +++ b/openpower/sv/po9_encoding/discussion.mdwn @@ -1,7 +1,20 @@ [[!toc]] +# introduction + +the purpose of this page is to create and evaluate alternative +encoding schemes that allow for a hybrid mixture of +(ultra-precious) 32-bit and 64-bit (actually `x86 REP`-like +prefixed) instructions. + +a specific view to attaining high-speed massive-wide multi-issue decode +is a high priority. therefore especially length-detection must be kept +brutally simple. + # alternative 32-64 encoding (1) +**superseded** + conflict to resolve: EXT90x and EXT232. they are indistinguishable. ``` @@ -51,6 +64,8 @@ Instruction allocation restrictions: # alternative 32-64 encoding (2) +**superseded** + requires reducing SVP64Single to 23 bits. luckily there are 2 spare the complexity of attempting to fit 32-bit instructions into @@ -93,7 +108,8 @@ Length detection: # alternative 32-64 encoding (3) -TODO +**current** + aim of this idea is to attempt simplification of area identification and length. the 55-bit area is eliminated and may only be reintroduced by sacrificing parts of EXT200-231, bear in mind that EXT209 is already -- 2.30.2