Reviewing the RISCV compressed instruction set, I had the thought why not let the system determine which instructions are compressed rather than have a preset compressed ISA ?
Create a dynamically alterable compressed to normal instruction lookup table. Say it’s used to translate the 4000 most commonly used instructions in an app. The app would be built using the compressed instruction set, and the lookup table for compressed instructions would be loaded when the app is loaded. There would have to be a table in the executable file that indicates which compressed opcode corresponds to an expanded one. The reason for the small 4000 entry table is that the table in hardware could be a bit larger to support multiple apps running at the same time.

This is going to look like a very variable length encoding, I think - are you thinking of encoding to the bit level, like a Huffman approach?

Maybe I should've mentioned the compressed code would be 16 bits (or rather 12 bits encoded into 16 bits) the other four bits being used as decode, for an uncompressed 32 bit code in order to keep the program counter increment sensible. The program counter would have to be able to increment by 2 bytes or 4 bytes. But basically it's similar to the Huffman approach. It might get tricky to perform debug as the debugger would have to look at the lookup table to know what instruction to display. In the debugger the address would only increment by two while displaying a 4 byte opcode. Somewhat like an inter-dimensional effect. If the first byte of the opcode is Fx then the instruction is a 12 bit compressed one. So they are all Fxxx. The remaining instructions would be 32 bit.

Ah, I see - a bit like Thumb, but more dynamic.

Arggh! Maybe scrap the idea. Sure I rebuilt the assembler to detect the 4000 most common opcodes, which it did. But it then has to output in another pass using the compressed opcodes. What happens ? The offsets of the branch instructions changes, unless the branch instructions are omitted from compression their compressed version won't match the original opcode. The compressed table would be out-of-sync. The same thing is true of other pointers to code that get loaded as immediate values. Looks like a lot of work would have to be done with the assembler. Now back to statically allocated compressed instructions.

Aaah, yes, of course. A stability problem. There was a thing with Transputer code whereby you might need quite a few passes for the variable lengths to stabilise.

Some more work was put into the assembler so that it excludes anything that might cause trouble from being compressed. Running the boot rom through the modified assembler for Thor reveals a vast savings 45% smaller code ! 50466 bytes versus 91600 originally. That doesn't include 10k for the lookup table. About 2600 instructions were converted to compressed versions. It remains to be tested in the simulator / FPGA though.
It was really easy to modify the instruction stage to incorporate compressed instructions.

An error was found in the byte counting that omitted counts for two byte instructions. So the real savings is closer to 25%. I knew the 45% number was too good to be true so I checked again. 66400 bytes vs. 91600.

Dynamically defined compressed instructions can be used to create a form of self-modifying code. If code 0200h = addi r1,r1,#10 the translation could easily be replaced by 0200h = andi r1,r1,#10 at runtime.
An instruction space identifier was added the Thor core. It's used to indicate which set of compressed instructions are active for a given set of compressed opcodes. It allows process to share the same set of compressed instructions with another process, or to use a different set. So the code 0200h in one set might be different than the code 0200h in another set.