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

[Jacob Lifshay]

On Mon, Dec 14, 2020, 00:08 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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" :)


lots of *guided* random guessing -- inspired by darwinian evolution.

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?
>

I can't guarantee it, but I'd expect a properly designed genetic algorithm
to give an encoding better than what we might design by hand.

Note that the genetic algorithm would be deciding which instructions to
include in the compressed encoding and which ones are left as 32-bit only.

Jacob