search

rrthomas / mit

A simple stack-based VM
Other
10 stars 3 forks source link

Make build-profile into a standalone program, `specialize-mit` #290

Closed apt1002 closed 5 years ago

apt1002 commented 5 years ago

The man page for the putative program should contain the information in features/Specializer.md, and the program should do roughly what make build-profile does.

However, the current make build-profile target is the round wrong way: the dependency on mit causes specializer.c to be regenerated, which requires running simulate-jit. Therefore, the work starts with simulate-jit and ends with mit --profile, whereas the user might reasonably expect the first step to be mit --profile and the final step to be building a new mit. Specifically, the final mit-profile.json is the result of running the new mit, not, as might be expected, its input.

Instead, specialize-mit should do one round of specialization.

There also seems to be a dependency problem: first, build-profile should not need to depend on libmitfeatures, as mit already does; secondly, we have found that despite depending on mit, mit is not always up-to-date when the body of build-profile is run.

rrthomas commented 5 years ago

Removing the dependency of build-profile on libmitfeatures indeed seems to work fine.

The reason that mit is rebuilt after running build-profile is that mit-profile.json has been updated, so mit is indeed out of date. This will be fixed by correcting the order of actions.

rrthomas commented 5 years ago

Having fixed the build-profile target and renamed it specialize-mit, it seems sensible to keep it as a make target, rather than make it into a script, because first, it depends on mit being up to date, and secondly, once mit --profile has been run, the simplest way to rebuild is to run make.

I have also moved the contents of Specializer.md into specializer.am and rewritten it.

rrthomas commented 5 years ago

We talked about making it possible not to build the specializer or other features. This would be a lot of work in the build system, so for now I've not done it. In particular, a minimal system is already available in libmit, and that could already be packaged separately by downstream distributors (as RPMs, .debs etc.). Rather than build yet another plugin system, it seems better to wait until we have our FFI system, and then dog-food that internally.