From 474971b0c666cfc22b9e20035d9268eb64dfb69b Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 31 Dec 2020 21:52:54 +0000 Subject: [PATCH] --- openpower/sv/overview.mdwn | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/openpower/sv/overview.mdwn b/openpower/sv/overview.mdwn index 39a5f1e00..633a5cd49 100644 --- a/openpower/sv/overview.mdwn +++ b/openpower/sv/overview.mdwn @@ -290,18 +290,25 @@ registers. In c this would be: Conceptually, to get our variable element width vectors, we may think of the regfile as instead being the following c-based data -structure: +structure, where all types uint16_t are in little-endian order: typedef union { uint8_t actual_bytes[8]; uint8_t b[0]; // array of type uint8_t - uint16_t s[0]; + uint16_t s[0]; // array of LE ordered uint16_t uint32_t i[0]; uint64_t l[0]; // default OpenPOWER ISA uses this } reg_t; reg_t int_regfile[128]; // SV extends to 128 regs +Setting `actual_bytes[3]` in any given `reg_t` to 0x01 would mean that: + +* b[0..2] = 0x00 and b[3] = 0x01 +* s[0] = 0x0000 and s[1] = 0x0001 +* i[0] = 0x00010000 +* l[0] = 0x0000000000010000 + Then, our simple loop, instead of accessing the array of regfile entries with a computed index, would access the appropriate element of the appropriate type. Thus we have a series of overlapping conceptual arrays -- 2.30.2