ART@ACC.ARPA (Art Berggreen) (09/20/85)
> I am looking for information on running UNIX system V on the Micro-VAX. > Particularly I would like to know: > > a) What are the major differences between the Micro-VAX and VAX-780 bus > architecture? Do I have to rewrite any drivers in order to put the AT&T > System V VAX-780 release onto the Micro-VAX? > > b) Beside DEC's ULTRIX, are there any other UNIX systems that can be run > on the Micro-VAX? You didn't specify which uVAX (I or II) but I'll assume a uVAX-II since I doubt it would be worth the effort for a uVAX-I. Any code in the UNIX kernel which is conditional upon cpu type will have to be examined and support for the new processor type added. This may not require significant changes, just lots of work adding the new conditionals. The overall bus architecture of the uVAX-II is similar to that of the UNIBUS VAXen (especially the 730). The CPU and cache have a private bus to the memory and a bus adapter connects the QBUS to the memory bus. The bus adapter maps a portion of physical address space out to the QBUS. In the uVAX-II there are two areas. One 4MByte section maps to the full QBUS for memory type references. Another 8KByte section is used for peripheral (BBS7) type references. The bus adapter also has a set of mapping registers to map pages on the QBUS into pages of main memory. UNIBUS machines have 496 map registers needed to map the 18 address bit UNIBUS (I/O page is not mapped). The uVAX-II has 8K mapping registers to map the entire 22 address bit QBUS. The QBUS can be used as an 18 bit bus by only using the first 256KBytes of address space (and only first 496 map registers). This makes the uVAX-II look very much like a UNIBUS VAX. Interrupts are direct vectored like the 730 and 750. As far as device drivers go, many of the newer DMA QBUS devices may not look like any UNIBUS devices (because of 22 bit address registers), so new device drivers may be needed. Any interrupt driven device which has a UNIBUS equivalent should be easier. Documentation for the hardware may be a problem, uVMS fiche listings would probably help. Ultrix is the only UNIX I know of that runs on uVAXen. I don't think BSD 4.3 will support uVAXen, and I doubt ATT will do it. Uniq may be doing System V support on uVAXen. "Art Berggreen"<Art@ACC.ARPA> ------
chris@umcp-cs.UUCP (Chris Torek) (09/20/85)
Another problem is that some of the string instructions on the uVax-II are ``minicoded'': the arguments are put in the appropriate registers, then the CPU traps somewhere to let an assembly code routine handle the work. Examples are scanc and matchc, but, I have been told, *not* movc3. I have also been told that the code which implements these instructions is nontrivial. It is not on the 4.3 alpha tapes, and I doubt that it will be included in the 4.3 distribution. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
dave@uwvax.UUCP (Dave Cohrs) (09/20/85)
> Another problem is that some of the string instructions on the > uVax-II are ``minicoded'': the arguments are put in the appropriate > registers, then the CPU traps somewhere to let an assembly code > routine handle the work. Examples are scanc and matchc, but, I > have been told, *not* movc3. movc3 and movc5 are both 'real' instructions on the uvax-I, so I assume they are also real on the uvax-II. The silly COBOL instructions are all simulated in software. I've looked at the code -- they are long and rather complex (I think that DEC was trying for efficiency). The emulated instructions on the uvax-I are: ashp, cvtlp, cvtps, crc, addp4, subp4, cvtpt, subp6, milp, cvttp, divp, cmpc3, scanc, spanc, cmpc5, movtc, movtuc, movp, cmpp3, cvtpl, cmpp4, editpc, matchc, locc, skpc. Of course, using these instructions should still be faster in general usage that a C routine doing the same thing because the assembly code *should* be well optimised. -- Dave Cohrs (608) 262-1204 ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave dave@wisc-romano.arpa