On Fri, 5 May 2023 at 01:23, Jun Sun <j...@junsun.net> wrote: > > Agree on the usefulness of generating the same test. That is the reason > behind adding --randseed option. Once a seed is set, it always generates the > same sequence of instructions. > > Basically with this patch, > > by default you will generate random instruction sequences for most testing > cases > you can provide a random seed option in the commandline to generate a > deterministic instruction sequence > > Without this patch, > > we always get one fixed sequence (ie. random seed == 0 case) > Otherwise we would have to manually modify code to generate random > instruction sequences or generate a different fixed sequence. > > Hope this clarifies things a little bit.
Mmm; it comes down to: should we default to 'time' and require the user to specify --randseed 0 to get the old behaviour; or do we retain the current behaviour as the default and let the user pass an option if they want a non-reproducibly random output. Alex, what do you reckon? You probably have been using risugen more actively than me recently. I guess I vaguely lean to "default to randomize(time)". Also, should we make risugen print the random seed to stdout so you can repro it even if you didn't pass --randseed initially? Now that the random-seed-setting is 6 lines instead of 1, this should definitely be abstracted out to a function in the common code and not repeated in each per-arch file. thanks -- PMM
