[Simh] cpu idle with NetBSD

Michael Bloom mabloom at dslextreme.com
Wed Apr 11 00:49:04 EDT 2012


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/20120410/82f6a682/attachment-0002.html>


More information about the Simh mailing list