Fuse bluespec binaries into a busybox-like tool

[bpfoley]

The binaries for$(UTILEXES) $(SHOWRULESEXES) consume a substantial amount of disc space on top of $(BSCEXES) even though they mostly just re-use the functionality implemented in modules also used by bsc itself.

On my Mac, stripped -O2 builds have the following sizes

$du -sh
38M bsc
5.6M    bsc2bsv
 12M    bsv2bsc
3.3M    dumpbo
3.6M    dumpba
2.6M    vcdcheck
6.2M    showrules

Note that bsc is 38MB and all the other binaries sum to 33.3MB.

This disc space usage can be a (minor) efficiency concern in continuous integration environments, and also matters if you want to build minimal docker images and the like.

It also slows down the complete tool build by causing an individual (large) link to occur for each binary.

We could replace all these tools with a single binary; use symlinks to link all the old binary names to our single binary; determine which command we're actually running based on argv[0]; and dispatch to the correct Main based on that.

[quark17]

Note that only bsc, bluetcl, and bluewish are currently being built and installed by the default top-level make target. The other tools aren't contributing anything to build time or installation size (unless the installation is being built in some other way). Has this issue been opened in anticipation of wanting to include the other tools in the release? Note that if you're in the src/comp/ directory, the default target appears to be all which does build them all (but doesn't install them). Perhaps that has caused some confusion?

My suggestion would be to eliminate some of these tools, replace with with a bluetcl script, or make it a bluetcl command. I'd be less inclined to make it part of BSC, but I'm not opposed to that. Some notes:

The vcdcheck program doesn't really use any of BSC's code (just some I/O routines) so I'd say to remove it, not merge it. It exists to be used by the BSC test suite, to check that VCD files generated by Bluesim are well-formed. You could consider moving its code to the testsuite repo, and build it there, not here; although, if there's a better way to verify the validity of the VCD files, then you might not even need this program.

The showrules program does share the VCD module with vcdcheck (and they are the only programs here that use that module, as I can tell). I don't think that anyone uses showrules and you could probably remove it. Its purpose was to take a VCD generated from the execution of a BSV design, and alter the VCD (which updates all the state in one go on each clock cycle) into a new VCD that has micro steps within each clock cycle (for each rule executing in sequence within that clock cycle). If its only use of the BSC codebase is to open .ba files and look at the schedule, then that can be done via bluetcl (or some new API), and it could be added to the util directory to could even become a tool in another repo (assuming that someone thinks it's useful enough to keep).

The dumpbo and dumpba programs are used by the testsuite, and are possibly useful to a developer who wants to dump the contents of an intermediate file. In the test suite, I think only its exit code is used (to test that the intermediate file can be read back in) and that behavior can be replaced with a call to bluetcl that does a load command. If it's useful to the user to also dump the file contents, then that dumping could easily be added to bluetcl (if it's not already there), and these programs could be replaced with a script that just loads and then dumps.

Similarly, the bsc2bsv and bsv2bsc programs could be replaced with bluetcl scripts that just parse and pretty print (adding those actions if they don't already exist). The bsc2bsv command was created back when BSV syntax was new, and it was used to automate the conversion of files. It was never perfect, so the user generally has to massage the output, to make it valid code; but for converting large amounts of code, it at least automates the bulk of the work. The reason it's not perfect is that it was just thrown together by calling the parse command and then the pretty print command, and the pretty printer is used at most on certain kinds of small expressions (in error messages) and we don't test that its output on an entire file can be read back in. As I said, these could certainly be implemented by a bluetcl script. I doubt that anyone uses these, although maybe there's more need now that Classic/BH is becoming more used.

[bpfoley]

That's a good point. One of my typical flows is just to do a make -C comp all, which is partly why I noticed it.

Personally I've no strong desire for any of the tools (although dumpbo and dumpba might be useful for lower level development work.)

When you say 'foo could be done by bluetcl', do you mean that we'd have to add a some random Haskell code to be linked into bluetcl and that we'd expose as Tcl bindings? Or do you mean this functionality already exists? I must admit I haven't really looked at what (or how) bluespec behavior is exposed using Tcl.