2020-11-30

	* 238: Settled the N-without-M issue, it was likely an error in
	the tables.  Raised an inconsistency in decoder pseudocode's
	reversal of M and N.  Returned to the uncertainty and need for
	specifying how to handle conflicts between
	standard-then-compressed followed by 10-bit with M=0.  Raised
	issue of missing documentation that branch targets are always
	uncompressed, not just 32-bit aligned.  Raised issue of the
	purpose of M and N bits, particularly in unconditional branches.
	Explained why I believe phase 1 decoder hsa to look at Cmaj.m bits
	to tell whether or not N is there, brought crnand and crand
	encodings as example, and asked whether crand with M=0 should
	switch to 32-bit mode for only one insn, because the bit that
	usually holds N=1, or permanently, because there's no N field in
	the applicable encoding.  (2:33)

	* 238: Detailed the motivations for my proposal of bit-shuffling
	in the 16-bit encoding, to reduce wires and selections in the
	realigning muxer.  Restated my question on N without M as I can't
	relate the answer with the question, it appears to have been
	misunderstood.  Further expanded on the advantages of moving the
	Cmaj.m and M bits as suggested, even going as far as enabling an
	extended compressed opcode reusing the bit that signals a match
	for a 10-bit insn in uncompressed mode.  (3:29)

2020-11-29

	* 238: Noted some apparent contradictions in the rejection of
	extended 16-bit insns in the face of 16+16-bit insns.  Luke hit me
	with clarification that there's no such thing as a 16+16-bit insn
	in compressed mode, and I could see how I'd totally made it up by
	myself by reviewing the proposal.  Hit and asked other questions:
	what's the N for when there's no M, and what are the SV prefixes
	mentioned there, now that I no longer assume them to be something
	like extend-next.  Then I recorded some thoughts on minimizing the
	bits the muxer has to look into by making the bits that encode N,
	Cmaj.m and M onto the same bits that, in traditional mode, encode
	the primary opcode.  Finally, I was hit by the realization that,
	if we change the perspective from "uncompressed insns used to be
	32-bit only" to "uncompressed can be 32- or 16-bit depending on
	the opcode", on account of the 10-bit insns, the need for taking
	the opcode into account to tell whether we're looking at a 16- or
	32-bit insn, so why is it ok there, but not ok in compressed mode?
	Finally, I propose an encoding scheme that encodes lengths of
	subsequent insns in an early insn, achieving more coverage for
	16-bit insns, better limit compression, far more flexible mode
	switching, enabling savings at far more sparse settings, and
	without eating up a pair of primary opcodes: the 32-bit
	mode-switching insn could even be an extended opcode, though it
	would probably not have as many pre-length encoding bits then.  It
	would fit an entire 16-bit insn, which could do useful work, or
	queue up further pre-length bits, that correspond to static
	upcoming insns and tell whether to decode them as 32-bit or as
	(pairs of?) 16-bit ones.  Compared max ratio, representation
	overhead, and break-even density.  Shared some more thoughts on
	48- and 64-bit insns.  (7:39)

	* 532: Got a little confused about some encodings; it's not clear
	whether the N and M bits in 16-bit instructions have uniform
	interpretation, or whether some proposed opcodes are repurposing
	them.  I'm surprised with such short immediate operands in the
	immediate instructions, if they don't get a 16-bit extension, or
	otherwise with the apparent requirement for an extended 16-bit
	immediate for something as simple as an mr encoded as addi.  Asked
	for clarification.  Not sure about how to proceed before I get it;
	the logic of the estimator would be too significantly impacted.
	(2:48)

2020-11-28

	* 532: Figured out and implemented the logic to infer mode
	switching for best compression under attempt 1 proposed encoding,
	namely with 10-bit insns, 16-bit insns, 16+16-bit insns, and
	32-bit insns.  10-bit insns appear in uncompressed mode, and can
	be followed by insns in either mode; 16-bit ones appear in
	compressed mode, and can remain in compressed mode, or switch to
	uncomprssed mode for 1 insn or for good; 16+16-bit ones appear in
	compressed mode, and cannot switch modes; 32-bit ones appear only
	in uncompressed mode, or in the single-insn slot after a 16-bit
	that requests it.  If we find a 16-bit insn while we're in
	uncompressed mode, use a 10-bit nop to tentatively switch.  Insns
	that can be encoded in 10-bits, but appear in compressed mode, had
	better be encoded in 16-bits, for that offers further subsequent
	encoding options, without downsides for size estimation.  Insns
	that can be encoded as 16+16-bit decay to 32-bit if in
	uncompressed mode, or if, after a sequence thereof, a later insn
	forces a switch to 32-bit mode without an intervening switching
	insn.  Still missing: the code to select what insns can be encoded
	in what modes.  (6:42)

	* 532: Implemented a skeleton for compression ratio estimation,
	initially with the simpler mode switching of the 8-bit nop,
	odd-address 16-bit insns.  Next, rewrite it for all the complexity
	of mode switching envisioned for the "attempt 1" proposal.  (2:02)

2020-11-23

	* 238: Debating various possibilities of 16-bit encoding.  (5:20)

	* 532: Wrote a histogram python script, that breaks counts down
	per opcode, and within them, by operands.  (2:05)

2020-11-22

	* 529: Brought up the possibilities of using 8-bit nops to switch
	between modes, so that 16-bit insns would be at odd addresses, so
	that we could use the full 16-bits; of using 2-operand insns
	instead of 3- for 16-bit mode so as to increase the coverage of
	the compact encoding.
	* 238: Luke moved the comment above here, where it belonged.
	* 529: Elaborated how using actual odd-addresses for 16-bit insns
	would be dealt with WRT endianness.  Prompted by luke, added it to
	the wiki.
	* Wiki: Added self to team.  (11:50)

2020-11-21

	* 532: Wrote patch for binutils to print insn histogram.
	* Mission: Restated the proposal of adding "and users" to the
	mission statement, next to customers, as those we wish to enable
	to trust our products.  (6:48)

2020-11-20

	Reposted join message to the correct list.
	* 238: Started looking into it, from
	https://libre-soc.org/openpower/sv/16_bit_compressed/

2020-11-19

	Joined.