[Libre-soc-dev] v3.1B prefix

[Luke Kenneth Casson Leighton]

On 12/14/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Sun, Dec 13, 2020, 23:18 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
>> On 12/14/20, Alexandre Oliva <oliva at gnu.org> wrote:
>>
>> > 32-bit uncompressed instructions: 109169
>> > 16-bit compressed instructions: 7732
>> > 16-imm compressed-mode instructions: 14509
>> > 10-bit compressed instructions: 4057
>> >
>> > 10-bit mode-switching nops: 3398
>> > 10-bit mode-switching nops for imm-16: 10821
>> > 16-bit mode-switching nops after imm-16: 1876
>> >
>> > 10-bit nop+16-imm pairs above, backtracked to 32-bit: 9171
>> >
>> > Compressed size estimate: 521462
>> > Original size: 541868
>> > Compressed/original ratio: 0.962341
>>
>
> Maybe we should try to do something like make a genetic machine learning
> algorithm to decide which instructions and which immediate sizes to use?

aka "lots of random guessing" :)  i like random guessing QTY a
billion.  look up RIES some time
https://mrob.com/pub/ries/index-2.html
 https://en.wikipedia.org/wiki/Genetic_algorithm
>
> We could use some combination of compression ratio and decoder complexity
> as the fitness function

it needs coding up, which would take time.

*thinks*... do we have any level of confidence that the stats would be
high, here, i.e. would definitely produce good results?

remember these are still complex schemes.

can we first get a histogram of the runs of 16-32-16 candidates?

16-32-16 should include

* 1-8 16s
* 0-7 32s
* 0-7 16s

that gives up to a sequence of 15 16bitters.

l.

l.