(no commit message)
authorlkcl <lkcl@web>
Sat, 24 Sep 2022 23:11:45 +0000 (00:11 +0100)
committerIkiWiki <ikiwiki.info>
Sat, 24 Sep 2022 23:11:45 +0000 (00:11 +0100)
openpower/sv/overview/discussion.mdwn

index d9d00123550f676e9eedc5be65cd0417857026f3..2c488eabbf87f1a521c9f502d0caed538cbaaf05 100644 (file)
@@ -177,3 +177,36 @@ has to be solved in the ISACaller Simulator when elwidth overrides are
 completed (recall that the ISACaller Simulator uses a python class where
 numbers are indeed strict MSB0 defined, arithmetically).
 
+# Architecturally LE Regfile
+
+The meaning of "Architecturally" is that the programmer sees one definition,
+where that definition has absolutely no connection or imposition on precisely
+how the implementation is implemented (internally), **except** to comply with
+the definition as far as **external** usage is concerned (programs).
+
+This is the *canonical* Architectural definition of the regfile
+asuming a Little-Endian system, in the c programming language:
+
+    #pragma pack
+    typedef union {
+        uint8_t  b[];
+        uint16_t s[];
+        uint32_t i[];
+        uint64_t l[];
+        uint8_t actual_bytes[8];
+    } el_reg_t;
+
+    elreg_t int_regfile[128];
+
+Where things become complicated is how to transliterate the above into
+MSB0 numbering.  We start with some definitions:
+
+* bit-ordering below is in MSB0 order, prefix "b"
+* byte-ordering is in MSB0 order, prefix "B"
+* register-numbering is in **LSB0** order, prefix "r"
+* element-numbering is in **LSB0** order, prefix "e"
+
+First we define the contents of 64-bit registers:
+
+    r0 : | b0 b1 b2 b3 b4 b5 b6 b7 | ... | b56 b57 b58 b59 b60 b61 b62 b63 |
+         |        B0               | ... |  B7                             |