lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (11/01/90)
DEC has announced that it will build a "VAX RISC". I haven't heard any details: so, let's speculate. The killer problem is migrating the existing code. First, some of it is in assembler, so we would want a tool which turns VAX into VAX-R (RAX?). The tool doesn't have to generate great code: but it has to be correctness-preserving, or else know when it's stuck. Being stuck is OK only if it happens very rarely. Given the tool as a constraint: what could RAXen look like? A MIPS with stack-based calling convention and non-IEEE floating point?? Condition codes? What about the VAX vector unit? Trap handlers, and the stack searches for them? We know the page size... because they probably can't find all of the places where VMS assumed it. -- Don D.C.Lindsay
dik@cwi.nl (Dik T. Winter) (11/01/90)
In article <10948@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: > DEC has announced that it will build a "VAX RISC". I haven't heard > any details: so, let's speculate. ... > What about the VAX vector unit? ... If you look at it you will see that the design is already 'RISCy'. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
chris@mimsy.umd.edu (Chris Torek) (11/02/90)
In article <10948@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: >DEC has announced that it will build a "VAX RISC". I haven't heard >any details: so, let's speculate. >We know the page size... i.e., too small :-) >because they probably can't find all of the places where VMS assumed it. I would be inclined to believe otherwise, but I think a larger problem is that VMS has let the page size show through to applications; many no doubt depend on 512-byte pages. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
henry@zoo.toronto.edu (Henry Spencer) (11/02/90)
In article <10948@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: >Given the tool as a constraint: what could RAXen look like? A MIPS >with stack-based calling convention and non-IEEE floating point?? >Condition codes? What about the VAX vector unit? Trap handlers, and >the stack searches for them? The three things you need to fix/break :-) in the MIPS chip if you want easy mechanical code translation from the VAX would be floating-point formats, condition codes, and stack-frame layout. FP formats are pretty obvious; it is just conceivable that you might be able to get by with conversion instructions, using IEEE arithmetic for the real work, but inevitably people would get different answers and start screaming. Condition-code dependencies are all through VAX code and are subtle, although in most cases a sophisticated code analyzer could find them and cope with them if really necessary. Stack-frame layout is a pain because it will mean slower function calls, but there are undoubtedly a billion things that know about it, and things like pointer arithmetic make it very difficult to fix this mechanically. >We know the page size... because they probably can't find all of the >places where VMS assumed it. VMS would need a lot of fixing no matter what. The harder part is that if the VMS system calls make page size visible at all, e.g. as the quantum of user memory-allocation requests, then user code will depend on it. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
JONESD@kcgl1.eng.ohio-state.edu (David Jones) (11/03/90)
Everyone who is posting on this topic is assuming that a 512 byte page size is simply not viable on a RISC machine. Bearing in mind that the memory allocation size is not the paging I/O size, what is the actual performance hit incurred by using a smaller page? A small page means page tables are larger and a larger translation buffer is needed to cover the same address space. How much effectiveness does the translation buffer actually lose because of this? For a given memory reference pattern, the smaller page size probably means more page faults are incurred (especially if they are demand zero faults). A properly tuned OS doesn't spend much time in the page fault code, so what is the actual impact of the small page size? David L. Jones | Phone: (614) 292-6929 Ohio State Unviversity | Internet: 1971 Neil Ave. Rm. 406 | jonesd@kcgl1.eng.ohio-state.edu Columbus, OH 43210 | jones-d@eng.ohio-state.edu Disclaimer: A repudiation of a claim.