H------------------------------------------------------------------------,_Title: Test routines for Unibus Attribute.$_File: [PRAXISTST.UNIBUS]UNIBUS.TXT/_Author: J. M. Duffy _Created: 30-JUN-1981H------------------------------------------------------------------------AThis directory contains a series of modules which are designed toBdemonstrate the feature in the VAX Praxis compiler which generates@code to access data structures located in Unibus address space. AIT CANNOT BE STRESSED ENOUGH THAT THE CORRECT FUNCTIONING OF THIS)FEATURE IS ESSENTIAL TO THE NOVA PROJECT.#The files are organized as follows: Test files: 8 TEST16.PRX;2 -- test access to single word-sized items.< TEST32.PRX;2 -- test access to single longword-sized items.7 TEST8.PRX;2 -- test access to single byte sized items.7 TESTREAL.PRX:2 -- test access to single real numbers. = TESTLONGR.PRX:2 -- test access to single long_real numbers. . TESTARR8.PRX;3 -- index and copy byte arrays.6 LONGARR8.PRX;2 -- copy a long array of 8 bit integers/ TESTARR16.PRX;2 -- index and copy word arrays.3 TESTARR32.PRX;2 -- index and copy longword arrays.? TESTFIELD.PRX;2 -- Access fields of packed structure in array.8 TESTIMP.PRX;2 -- Import variable with unibus attribute.+ TESTMOVE.PRX;3 -- Move larger structures.C TESTPROC.PRX;3 -- Pass varible with unibus attribute to procedure.! TESTSTRNG.PRX;2 -- Move strings.8 TESTSTRUC.PRX;3 -- Access fields of a packed structure.2 TESTVEC.PRX;2 -- Access packed array of booleans.' TEST.PRX;3 -- template for test files.I UNIBUS.PRX;20 -- Main program, test access routines on Unibus multiport.* { failing routines are commented out.} Miscellaneous:1 MAPPER.PRX;8 -- Routine to map to the multiport.3 NSMsysutl.sps -- Provides system call for mapping. IOmodule.sps -- Text output.! NSMVAX.olb -- Objects for above. Command files:/ unibus.com -- compiles and links test program.3 { do not worry about message regarding "NVAST",& it is not relevant to problem. }DEach of the test modules contains two procedures, named test_xxxx_s,Band test_xxxx_u. It was felt that there should be an easy means ofFdetecting whether or not the unibus attribute was actually recognized.ETherefore the two procedures in each module are identical, except for@the fact that the _s one deals with static variables, and the _UDversion deals with variables declared in unibus segments. This also/quickly verifies storage allocation questions. Results: 1The Unibus.prx module shows those routines which: a) did not compile7 b) compiled, but did not use the correct instructions.1 ( verified by actually mapping to the unibus. )C c) Compiled, but did not correctly recognize the unibus attribute.;As a matter of fact, only testarr8 contained code that bothDrecognized, and generated correct code. The single access routines,@with the exception of test32, also worked, but we knew that theywould. Suggestions:DThere are several kinds of accesses to the unibus that are problems:: 1) Moves of objects larger than 16 bits. Which further breaks down to:2 a) 16 < n <= 32 -- items which could normally be9 moved with longword-sized instructions. Also reals.3 b) 32 < n <= 64 bits -- items that could be moved7 with quadword-sized instructions. Also long_reals.& c) Things much larger than 32 bits. 2) Accesses of bit fields. a) single bit items. b) multiple bit items. GFor 1a, use two 16 bit transfers. For reals, 16 bit transfers to a tempGvariable is required. Similarly, for 1b). Do not use MOVC for strings,structures or arrays. KFor single bit items, I suggest using the BBS, BBC, BBSS, BBCC instructionsAto test, set and clear bits. For multiple bit fields, I suggest:3 MOVW (or MOVB) from appropriate word into a temp." INSV, EXTV, EXTZV from the temp.= MOVW (or MOVB) back to the multiport. (not needed on read.)KThe above seems much more efficient than doing alot of shifting and masking-Kinorder to use the BITW, BICW, BISW instructions. Also it shouldnt involvetJmuch modification of the use of INSV, EXTV ... that is already done in thepacked structure access code.NLanguage Change:IThe two test modules, testimp and testproc demonstrate a problem with theyLcurrent implementation of the unibus attribute. By tying it to the segment,Othere is no way to indicate to a procedure that the arguments are to be treateddLas if they were in Unibus space. Similarly, there is no way to know that anNimported variable is in unibus space. Both of these features are heavily usedKin the NSM - Network Shared Memory system. Therefore, we suggest that the iOattribute be associated with the TYPE of the variable. This makes sense, sincemPthe resultant code change is much the same kind of modification that takes place%when the type is defined as volatile.T