lxo/ChangeLog

   1 2020-12-06
   2
   3         * 532: Adjusted the logic in comp16-v1-skel.py for 16-bit 16-imm
   4         rather than the 16+16 I'd invented.  Implemented the most relevant
   5         opcodes for 10-bit, and many of the 16-bit ones too.  Not yet
   6         implemented are conditional branches, Immediate, CR and System
   7         opcodes.  With all of nop, unconditional branch, ld/st,
   8         arithmetic, logical and floating-point, we get less than 3%
   9         compression in GCC, with not-entirely-unreasonable reg subsets.
  10         It's not looking good.  (8:27)
  11
  12 2020-12-02
  13
  14         * Microwatts meeting.
  15         * 238: Added some thoghts on bl and blr, and implications about
  16         modes.  Also detailed my worries about how to preserve dynamic
  17         state, specifically switch-back-to-compressed-after-insn, across
  18         interrupts.  (1:44)
  19
  20 2020-11-30
  21
  22         * 238: Settled the N-without-M issue, it was likely an error in
  23         the tables.  Raised an inconsistency in decoder pseudocode's
  24         reversal of M and N.  Returned to the uncertainty and need for
  25         specifying how to handle conflicts between
  26         standard-then-compressed followed by 10-bit with M=0.  Raised
  27         issue of missing documentation that branch targets are always
  28         uncompressed, not just 32-bit aligned.  Raised issue of the
  29         purpose of M and N bits, particularly in unconditional branches.
  30         Explained why I believe phase 1 decoder hsa to look at Cmaj.m bits
  31         to tell whether or not N is there, brought crnand and crand
  32         encodings as example, and asked whether crand with M=0 should
  33         switch to 32-bit mode for only one insn, because the bit that
  34         usually holds N=1, or permanently, because there's no N field in
  35         the applicable encoding.  (2:33)
  36
  37         * 238: Detailed the motivations for my proposal of bit-shuffling
  38         in the 16-bit encoding, to reduce wires and selections in the
  39         realigning muxer.  Restated my question on N without M as I can't
  40         relate the answer with the question, it appears to have been
  41         misunderstood.  Further expanded on the advantages of moving the
  42         Cmaj.m and M bits as suggested, even going as far as enabling an
  43         extended compressed opcode reusing the bit that signals a match
  44         for a 10-bit insn in uncompressed mode.  (3:29)
  45
  46 2020-11-29
  47
  48         * 238: Noted some apparent contradictions in the rejection of
  49         extended 16-bit insns in the face of 16+16-bit insns.  Luke hit me
  50         with clarification that there's no such thing as a 16+16-bit insn
  51         in compressed mode, and I could see how I'd totally made it up by
  52         myself by reviewing the proposal.  Hit and asked other questions:
  53         what's the N for when there's no M, and what are the SV prefixes
  54         mentioned there, now that I no longer assume them to be something
  55         like extend-next.  Then I recorded some thoughts on minimizing the
  56         bits the muxer has to look into by making the bits that encode N,
  57         Cmaj.m and M onto the same bits that, in traditional mode, encode
  58         the primary opcode.  Finally, I was hit by the realization that,
  59         if we change the perspective from "uncompressed insns used to be
  60         32-bit only" to "uncompressed can be 32- or 16-bit depending on
  61         the opcode", on account of the 10-bit insns, the need for taking
  62         the opcode into account to tell whether we're looking at a 16- or
  63         32-bit insn, so why is it ok there, but not ok in compressed mode?
  64         Finally, I propose an encoding scheme that encodes lengths of
  65         subsequent insns in an early insn, achieving more coverage for
  66         16-bit insns, better limit compression, far more flexible mode
  67         switching, enabling savings at far more sparse settings, and
  68         without eating up a pair of primary opcodes: the 32-bit
  69         mode-switching insn could even be an extended opcode, though it
  70         would probably not have as many pre-length encoding bits then.  It
  71         would fit an entire 16-bit insn, which could do useful work, or
  72         queue up further pre-length bits, that correspond to static
  73         upcoming insns and tell whether to decode them as 32-bit or as
  74         (pairs of?) 16-bit ones.  Compared max ratio, representation
  75         overhead, and break-even density.  Shared some more thoughts on
  76         48- and 64-bit insns.  (7:39)
  77
  78         * 532: Got a little confused about some encodings; it's not clear
  79         whether the N and M bits in 16-bit instructions have uniform
  80         interpretation, or whether some proposed opcodes are repurposing
  81         them.  I'm surprised with such short immediate operands in the
  82         immediate instructions, if they don't get a 16-bit extension, or
  83         otherwise with the apparent requirement for an extended 16-bit
  84         immediate for something as simple as an mr encoded as addi.  Asked
  85         for clarification.  Not sure about how to proceed before I get it;
  86         the logic of the estimator would be too significantly impacted.
  87         (2:48)
  88
  89 2020-11-28
  90
  91         * 532: Figured out and implemented the logic to infer mode
  92         switching for best compression under attempt 1 proposed encoding,
  93         namely with 10-bit insns, 16-bit insns, 16+16-bit insns, and
  94         32-bit insns.  10-bit insns appear in uncompressed mode, and can
  95         be followed by insns in either mode; 16-bit ones appear in
  96         compressed mode, and can remain in compressed mode, or switch to
  97         uncomprssed mode for 1 insn or for good; 16+16-bit ones appear in
  98         compressed mode, and cannot switch modes; 32-bit ones appear only
  99         in uncompressed mode, or in the single-insn slot after a 16-bit
 100         that requests it.  If we find a 16-bit insn while we're in
 101         uncompressed mode, use a 10-bit nop to tentatively switch.  Insns
 102         that can be encoded in 10-bits, but appear in compressed mode, had
 103         better be encoded in 16-bits, for that offers further subsequent
 104         encoding options, without downsides for size estimation.  Insns
 105         that can be encoded as 16+16-bit decay to 32-bit if in
 106         uncompressed mode, or if, after a sequence thereof, a later insn
 107         forces a switch to 32-bit mode without an intervening switching
 108         insn.  Still missing: the code to select what insns can be encoded
 109         in what modes.  (6:42)
 110
 111         * 532: Implemented a skeleton for compression ratio estimation,
 112         initially with the simpler mode switching of the 8-bit nop,
 113         odd-address 16-bit insns.  Next, rewrite it for all the complexity
 114         of mode switching envisioned for the "attempt 1" proposal.  (2:02)
 115
 116 2020-11-23
 117
 118         * 238: Debating various possibilities of 16-bit encoding.  (5:20)
 119
 120         * 532: Wrote a histogram python script, that breaks counts down
 121         per opcode, and within them, by operands.  (2:05)
 122
 123 2020-11-22
 124
 125         * 529: Brought up the possibilities of using 8-bit nops to switch
 126         between modes, so that 16-bit insns would be at odd addresses, so
 127         that we could use the full 16-bits; of using 2-operand insns
 128         instead of 3- for 16-bit mode so as to increase the coverage of
 129         the compact encoding.
 130         * 238: Luke moved the comment above here, where it belonged.
 131         * 529: Elaborated how using actual odd-addresses for 16-bit insns
 132         would be dealt with WRT endianness.  Prompted by luke, added it to
 133         the wiki.
 134         * Wiki: Added self to team.  (11:50)
 135
 136 2020-11-21
 137
 138         * 532: Wrote patch for binutils to print insn histogram.
 139         * Mission: Restated the proposal of adding "and users" to the
 140         mission statement, next to customers, as those we wish to enable
 141         to trust our products.  (6:48)
 142
 143 2020-11-20
 144
 145         Reposted join message to the correct list.
 146         * 238: Started looking into it, from
 147         https://libre-soc.org/openpower/sv/16_bit_compressed/
 148
 149 2020-11-19
 150
 151         Joined.