On Wed, Apr 11, 2012 at 12:49 AM, Michael Bloom <mabl...@dslextreme.com> wrote: > 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
Hello! Mike, what were you looking for when you clicked there? That's how his resource presents use with zip files of his work. In fact if you were to take a look at one of the GitHub offerings, you'd see a similar method. Next Question: Cygnus was glommed by Red Hat because of its interest in eCos an interesting and sadly difficult to make work Real Time Library, (Not an OS, they expect you to do all the work and they provide the libraries, and the tool chains. It's up to you the user to build the program that will run there, and eventually graft it into a real OS. Although they did claim that it supported a number of processors fully and did there become an OS.) however that part got spun off years later leaving them holding the bag for the Cygnus tool chains. The question is, "What company were you thinking of? Please explain off list." Mark sorry for stealing your thunder, but I thought I'd explain what happens with that style link. ----- Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
