---------- Forwarded message ---------
From:
Karl Semich <0xloem@gmail.com>Date: Mon, Apr 25, 2022, 11:17 AM
Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC
here is my present nascent idea, unsure:
- instrument sources to log their writes and reads, and use the logs as input data
- during compilation, use inotify to log which files are read from, and use these files as output data to train
- change to different source history points and shuffle configuration options to produce more data
- when input data is too large, add further trainable models to shrink it to fewer inputs as their output
- when output data is too large, parameterise the generation to generate only part at once
- run the code in qemu for the architecture so as to generate data for multiple architectures
- if timing is important and the instrumentation changes the timing, this could be measured and compensated for arithmetically
i'm a little confused on how logging might work in qemu. thinking of changing bootblock assembler to log things. seems this would best be done via a debugger with qemu that can act on the instructions themselves, not sure.
it seems it might also be good to measure code coverage so as to train only around code that is actually executed.
given there is a lot of hidden behavior, structures mutated without port writes, it could be good to err on the side of more data and more training expense.
or if things are limited to ordered port writes, it could be incredibly simple.
it seems to me x86 or arm makes more sense, so the code blocks could be executed on a normal consumer system.