SIMH on low overhead platform

[Chris Hanson]

On Aug 20, 2020, at 4:30 AM, Jan-Benedict Glaw <jbglaw at lug-owl.de> wrote:

> It's debateable whether or not the all-in-one builds are good or bad.
> Ie. GCC went into quite some development effort to gain LTO (link-time
> optimization) up'n'running, which was built quite exactly to allow
> optimizations that would otherwise only be possible if all sources are
> compiled in one run.

Link-time optimization has been a thing for a few decades, independent of whether GCC & GNU ld supported it. And very few compilers actually do anything any differently when all of the sources are passed in one go; to follow the spec, the compiler must consider each compilation unit independently, which it'll typically do by spawning one compilation process per compilation unit.

This also means the build system can't manage the build's parallelism, which is something you really want on a large project.

>  With any halfway modern hardware, build times probably don't really
> matter. Sure, if you're sitting in front of it waiting to finish a
> build, every second feels like ... ages.

Build times really do still matter. On my modern hardware SIMH still takes long enough to build that it's a hassle.

>  However, in my experience speed isn't really all that important.
> Correctness is. And the Makefile quite works, even without pulling in
> all the GNU autoconf or CMake stuff.

In my experience the more complex the Makefile, the less likely it is to be correct, and there's an enormous amount of unnecessary complexity in SIMH's Makefile—especially since it doesn't just build the simulators but also runs their tests without being instructed to. SIMH's Makefile results in a lot of unnecessary rebuilding and waiting.

>  On my laptop, a `make -j4' (building all simulators and running
> their tests) takes some 6min 20sec. Fair enough. Building just one
> (ie. ,/BIN/vax aka. vax3900 which I care the most about personally) is
> a matter of 21 seconds. Sure, that could be faster with careful
> dependency tracking, but that's okay for me.

You don't even need careful dependency tracking to improve this, just regular make behavior. What's more, the way the Makefile is currently constructed interferes with your use of `make -j4` by producing unnecessary output.

In short, cleaning up the build to work like any other make-based project would result in faster builds and make SIMH easier to work on for people interested in doing so.

  -- Chris