Vax Architectural Assessment ============================ a) Virtual Memory The Vax provides a 32 bit virtual memory of which half is reserved for the system - this is very comparable to 2900 with two 31 bit virtual memory - public and local. Here however the similarity ends; while 2900 provides 8192 segments of 256 pages the Vax provides only 2**21 pages. The segmented scheme provides several advantages in that the protection mechanism is more economically administered via segments than pages and it is less wasteful to find space for a separate page table for each actual segment in use than to keep one large contiguous one. Vax does allow the page tables themselves to be paged which neatly avoids the store management problem at the non trivial cost of further virtual store interrupts. The Vax scheme does result in some pressure on the "spare" bits in the page table (ie those not required for the base address of the page). The protection information is compressed into four bits per page as against the 2900 which allows 10 bits per segment. As a result of this there is not a "used" bit in the Vax page tables which makes it very difficult for the operating system to discover which pages a program is using. This must be regarded as a serious defect which will be particularly noticeable at the very high levels of interactive loads that ERCC machines have traditionally been required to support. b) Paging Strategy VAX/VMS uses a demand paging strategy with variations designed to ease the problems of having no "used" bits in the page tables. Pages are discarded from processes into a pool from which pages are subsequently written out when the free page list falls below a certain threshold. The hope is that pages discarded in error can be recovered before being written out. A further variation is that a complete track is fetched on a demand page into free page frames. This minimises head movements when (say) copying large areas of virtual store. At high levels of interactive demand these features can combine adversely. As the CPU is switched around various users they demand pages and by bringing in complete tracks flush the free pages list and hence the pool. By the time the round robin starts for the second time none of the pages of the first process are left in the pool and by re-demanding his pages he will in turn flush subsequent users pages to the disc. The pool is also vulnerable to processes which exhibit unstable paging behaviour. c) Compiler Target Machine Vax has a rich order code and a large variety of operand formats. It is in general very adequate apart from a rather unsatisfactory procedure call. This call lacks any method of specifying the called procedure's linkage area - thus all code is essentially non sharable. Further the procedure parameters are separated from the local variables. This is fine for simpler languages like Fortran, C and Assembler but penalizes the more modern languages like Simula and Ada which are forced to maintain a double display. The very richness of the order code means that many possible instruction sequences can be generated for a given task and this is likely to mean complex compilers which compile rather slowly. This factor together with the considerable extra costs of a compulsory link step make the Vax less than satisfactory as a program development or teaching engine. On the other hand the performance of optimised code is likely to be very high and the Vax is likely to show up well in any CPU dominated benchmarking. The Object module format is very dated; all compiler output must pass through a linker which binds the module and all referenced subroutines into a single clod of executable code. There are no facilities for dynamic linking or loading and service modules will appear many times on disc - linked with different calling modules. The only palliative is for the System Manager to "install" frequently used modules in the system; these then are not linked with each calling program. EMAS experience suggest that the System manager is not well able to make such selections in the general free for all of a University environment. d) Conclusion The architecture of the Vax is clearly influenced by its evolution from the Mini world and is not particularly suitable as a replacement for the current mainframes in Edinburgh. The above considerations suggest that the Vax is at its best in batch or near batch environment running highly optimised programs or packages which do not involve undue amounts of paging. The performance is likely to degrade rapidly when the number of active processes require more main store than provided. If it is to be used interactively it should be provided with ample main store and the number of simultaneous users restricted to that which experience shows is "reasonable".