[Libre-soc-dev] v3.1B prefix
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Dec 14 08:07:44 GMT 2020
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>
>> 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
> 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.
More information about the Libre-soc-dev