SIMH on low overhead platform

[Jan-Benedict Glaw]

On Tue, 2020-08-18 19:52:47 -0700, Chris Hanson via cctalk <cctalk at classiccmp.org> wrote:
> On Aug 18, 2020, at 5:50 PM, Grant Taylor via cctalk <cctalk at classiccmp.org> wrote:
> > On 8/17/20 5:34 PM, Chris Hanson via cctalk wrote:
> > > One thing that would make it much easier to experiment with SIMH
> > > in scenarios like this is if its build system wasn't horribly
> > > redundant.
> > 
> > Why are you mentioning SIMH's /build/ system in a thread
> > discussion boot times?
> 
> Did you miss the part where I said it would make it much easier to
> experiment with it if the build system was better? For example,
> switching between different networking implementations can require a
> rebuild.

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.

  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.

  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.

> > I wouldn't object if SIMH's /build/ took 20 minutes if it's
> > something that only happens every 3-12 months while starting on a
> > tiny Linux / *BSD / et al. system that /boots/ in a low number of
> > seconds.
> 
> SIMH improves quickly enough that you won't want to do a 20 minute
> build every 3-12 months, but instead perform new builds with some
> regularity.

  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.

  (What bugs me more is that Debian doesn't have up-to-date SIMH
packages, so I have to either use that stuff from stone age or package
it myself...)

> Between that and ease of experimenting (or the lack thereof) a bad
> build system can really hold back a project.

  I suspect that any one user probably only uses one or two
simulators, not all of them. They compile in a timeframe of some
20 seconds. Most of all users won't be active SIMH hackers, so they
will have that just once in a while when they `git pull'.

  If I were to start "from scratch" with SIMH, the steepest part in my
learning curve was to get it properly configured to run something
"useful."  Building isn't a real issue IMHO. What would be worth a lot
would be a repository of well-crafted configs along with proper
startup and download scripts (for OS tapes / disk images.)

MfG, JBG

--