[Simh] cpu idle with NetBSD

Fri Apr 13 06:45:10 EDT 2012

Mark,

this is excellent.
Thank you very much.

Regards,
Z

________________________________
From: Mark Pizzolato - Info Comm [Mark at infocomm.com]
Sent: Friday, April 13, 2012 3:47 AM
To: Michael Bloom; simh at trailing-edge.com
Subject: Re: [Simh] cpu idle with NetBSD

Hi Michael,

What I actually sent to the NetBSD folks was:

#define cpu_idle() do { _splset(splx(1)); } while (/*CONSCOND*/0)

On OpenBSD the change is:

#define cpu_idle_cycle()        do { _splset(splx(1)); } while (0)

On both OSes, the changes are to the respective macro definition in /usr/src/sys/arch/vax/include/cpu.h

So, I’m avoiding IPL 7.  I changed to IPL 1 since IPL 1 isn’t currently used and it was actually the IPL used on the very old versions of NetBSD idle code which has since changed (the old Idle loop actually ran at IPL 1).  The set of IPLs used by the BSD operating systems hasn’t changed significantly in the past 30 years, so it isn’t likely to change much going forward either, and if it does we can always adapt to what may change when it happens.  Meanwhile, It appears that some folks in the NetBSD community have patched their kernels to run the idle loop at IPL 1 so they can trigger the older simh idle detection logic (which had other issues since it detected the transition to the idle state, but then left it when any simh device poll happened, even if it didn’t produce an interrupt to the guest system).

I’ve built a GENERIC kernel with the above change (THIS TOOK A REDICULOUSLY LONG TIME! LONGER ON NetBSD than OpenBSD!) and tested it with a modified simh vax.  It works fine and idles well, so I’ve pushed the changes to the code in the master branch of the github repository.

Hopefully, If these changes gets accepted into the source code of either NetBSD and/or OpenBSD idling will just work right in the future.  Worst case, folks can apply the patch themselves and rebuild a kernel.

The name of the zipball which is returned is strangely named and potentially confusing, but it actually gets the contents of the desired branch.  The zipball name seems to be related to the parent of the branch in question.  The code you pull down using that mechanism is the current state of the ‘v3.9-0-rc1’ branch which actually contains the updates bringing it to v3.9-0-rc2 plus some other compiling fixes since the v3.9-0-rc2 announcement.  Pulling down https://github.com/markpizz/simh/zipball/master will return the codebase for what happens beyond the v3.9-0 release.  The tail part of the name (g15570e5 in this case) is the git commit hash (actually part of the hash, but unique enough to locate which commit in the repository it actually represents).  That commit hash uniquely identifies the branch and commit.  The web interface to this is really providing simple (hopefully somewhat familiar) ways for folks to browse and extract things from the repository.  The names it uses are effectively arbitrary.  Meanwhile, the github site for this repository provides a download page where I can post specific files which I get to place there with whatever names I want.  From time to time, I have extracted parts of some branches in the repository and left them available on the download page.  The process of doing this is an extra step or two which I don’t take the time to do that often.  I therefore have referred folks to the automatic links which will dynamically pull these zip files directly from the repository.

-          Mark

From: Michael Bloom [mailto:mabloom at dslextreme.com]
Sent: Tuesday, April 10, 2012 9:49 PM
To: Mark Pizzolato - Info Comm; simh at trailing-edge.com
Subject: Re: Re: [Simh] cpu idle with NetBSD

Hi Mark,

I like the idea of splx(splx(7)),  but it might be good to make the level configurable.  Currently, the lowest software interrupt used on NETBSD is level 8 for softclock,  but conceivably another system (or a future version) might have an additional software interrupt level and make use of 7.

Regarding your last paragraph, there are actually (believe it or not) still job postings for people with VAX experience.  Including various BSD's, not just VMS.

There is a surprising amount of application software out there that still runs on vaxes,  but the cost of maintaining those machines must keep increasing.  And there is more support available for NETBSD (which can run 4.3BSD a.out's) via the net or a company similar to Cygnus than there is for, say,  "More/BSD", whose vendor disappeared years ago.  Replacing a Vax running that system with a simulator running NETBSD may make sense to those with a large investment in applications that run on their vaxes.

Also, clicking on https://github.com/markpizz/simh/zipball/v3.9-0-rc1 unexpectedly downloaded a file named "markpizz-simh-v3.8-2-rc2-17-g15570e5.zip".

- michael

On 01/-10/-28163 11:59 AM, Mark Pizzolato - Info Comm wrote:
Hi Chris,

There were issues like this on prior versions of simh.  (V3.8-1 and earlier), which you are running.

The latest (about to be released) version is v3.9-0-rc2 which has significant improvements to the idle implementation, including a solution to the issue you found.  My earlier comments were specifically referring to that new idle implementation for the VAX.

The release candidate which is close to release is available at https://github.com/markpizz/simh/zipball/v3.9-0-rc1
Save what that URL returns as a zip file and unpack it and build a vax simulator with networking support using:
       unzip –a zipfilename.zip
       cd markpizz*
       make vax

The key issue with recent versions of NetBSD is that earlier versions of the OS had the vax specific idle routine within an assembler module called subr.S .  The simh idle logic detects the code which is implemented for idle in subr.S.  Meanwhie, newer versions of NetBSD don’t carry this assembler code anymore and a much more complicated sequence of things going on, essentially all from compiled modules (from a little examination of the code I’ve done).  The structure of the idle management has been adjusted to accommodate the features we have on modern system… (Everything Multi-Core, HyperThreading, etc.) with some low level tasks delegated to the idle loop as well (page zeroing).  There is one platform specific callout to “cpu_idle().  cpu_idle() is defined in usr/src/sys/arch/vax/include/cpu.h.  It is defined to be a macro:  “#define cpu_idle() do {} while (/*CONSCOND*/0)”  A normal compiler wouldn’t generate any code for this macro.  If the macro instead was defined to be “#define cpu_idle() do {splx(splx(7))} while (/*CONSCOND*/0)”

I have sent a message to the NetBSD vax mailing list with the above suggested change to the base source code.  Maybe it will get adopted.  OpenBSD has similar, but different code but I’ll make the same suggestion there as well.  Maybe this will end up built into these OS builds….

I come back to the question of why folks would want to run the new version of NetBSD on a simulated VAX when they can run a native one for their host platform which will be the same OS and be more naturally behaved.  If the point is merely to test to see if the OS still works, that’s great, but then you boot it test a few things and then turn it off.  Great idle support isn’t needed since it won’t be running continuously.

-          Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120413/0572accd/attachment-0002.html>