Minimax Simulator CLI

[prohde]

I created a first version of a CLI for the simulator by using picocli for command line argument parsing. The CLI takes one positional argument, the project file. Optionally, you can import/export as many memory dumps as you like.

There are long and short names for the parameters. Exporting takes a file name, start address, and end address. While importing takes a file name, the first memory address to fill with the imported data, and an optional value for the number of bytes to import. If the last parameter is left out, the complete file will be imported.

An example call could look like this:

java -jar minimax_simulator-2.0.0-jar-with-dependencies.jar ./test.zip --export-file ./export.bin --export-from 0 --export-to 0 --import-file ./import.bin --import-from 0 --import-bytes 5 -i ./import.bin -if 0 -e ./export2.bin -ef 1 -et 1

I made this PR a draft so that we can discuss this approach. I am open for discussions and/or adding/renaming parameters for the CLI version of the simulator.

Related to #57.

[prohde]

@AiyionPrime any suggestions or comments on this draft for a CLI version?

[AiyionPrime]

Ich bastel gerade ein bisschen damit herum; und denke, dass ein paar sinnvolle Default-Werte fehlen könnten.

Je nachdem, wie --import-from gedacht ist, gäbe es gerade zwei Interpretationen die mir schlüssig scheinen: Entweder --import-from bezieht sich auf die Ziel-Adresse im Speicher oder es bezeichet ein Offset in der zu lesenden Datei.

So oder so könnte es einfacher sein, den import zu gestalten, wenn der Paramter überflüssig ist. Er sollte je nach Implementation auf der ersten durch vorgehende Imports unbeschriebenen Speicherstelle liegen, oder 0 sein.

Ziel könnte sein, einen Speicher aus drei Dateien aufzubauen, indem man sie in der richtigen Reihenfolge importiert.

In Anlehnung daran würde ich auch --export-from und --export-to auf 0 und die größte benutzte Speicherstelle zurückfallen lassen, wenn sie ausgelassen wurden.

Die Doppeldeutigkeit --import-froms wird bis jetzt auch durch den Hilfetext nicht ausgeschlossen.

Starting address for the memory import.

Ansonsten gefällt mir der PR sehr gut.

[prohde]

I totally agree, the names and description are not yet perfect. I just didn't come up with better ones for the draft. Since there is no 'load from data with an offset in the file' option within the GUI, it was meant to be the memory address to where the content of the file should be written.

At this moment, I don't know how to get the first address after an import other than calculating it at the start of the CLI.

True, one could make the export simpler by making the parameters optional and export the entire memory by default. However, I wanted to discourage this. But if you think it would be a valid option, I won't argue about adding it.

[AiyionPrime]

Sorry, I overlooked this was in english. The calculation of the first address seems easy enough, I think calculatiing it at the start would be sufficient?

I have no strong opinion on this or the discouragement.

[prohde]

I updated the description of the parameters as well as default values. Default for export would be to dump the entire memory. On import, several files can be imported after another without specifying a starting address for each import.

[AiyionPrime]

The new descriptions do sound very good. I'll report back once I tested it.

[nilsmartel]

@AiyionPrime @prohde any updates on this? I think having this scriptable would be very important.

My use case would be to wait on file changes and rerun everything, in order to enable repl like behaviour

[prohde]

From my side it is fine. But I am open for any suggestions.

[AiyionPrime]

I had the PR running and tested it with our project, which worked well. I think I had a minor issue, but cannot find where I've written that down, yet. Nothing to block this though.

The project does lack some commitment of the institute owning it though, so don't expect a new version released soon, or even this merged.