lxo/ChangeLog

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