onto the stack prior to jumping to a subroutine, the cal led subroutine does up-level stack references to retrieve the argu ments. Other techniques i nclude using the stack as a com mon data area or attempt· i ng to manipul ate the caiJer's return address in order to alter the program f low.
Al l these techniques require re-cod ing. When we encoun tered code that passed parame ters on the stack, we modified the code to pass parameters i n registers. If a structure was being passed, separate memory was all ocated and the add ress of the struc ture passed in a register. In one case, NETACP used coroutines to perform specific functions to update a com mon data area a l located on the stack. This code was redesigned to eli minate the corou tines and up-level stack references. Another alternative wo uld have been to pass the address of the data area on the stack to the cal led rou tine.
Altering the program flow when error co n d i t ions were encountered was a lso a co m mon tech n ique used in the DECnet -VA X MACR0-32 code.
Digital Technical]ourllal Vol. 1 No. 4 5'pedal lssue 1992
Subroutines removed the return address from the stack and retu rned to the caller's cal ler. We modi fied the code to remove the up- level stack refer ence (the caller's return address) and return a flag in a register to signal the cal ler that a change in the program flow was desired.
Condition Codes
The Alpha A'"'XP arch itecture does not sup port globa l condition codes in the pro cessor status word . Some rou t i nes set condition codes and returned to the cal ler, which proceeded to perform a cond itional branch on the results of the called rou ti ne. A l l occurrences of this tech nique were changed ; rou ti nes now pass the result of a ny conditional test to the cal ler i n a register.Granularity and Atomicity IssuesH
The NETACP and NETDRIVER components access shared data structu res. Since NETDRlVER can i nterrupt N ETACP, the DECnet-VAX code rel ies on the atomicity of VAXinstructions to provide synchronized access to
shared fields i n the data structures. The DECnet -VAX code also rel ies on byte (8-bit) a n d word ( 16 -bit) granu larity for memory writes. Since the granular ity of Alpha AXP memory wri tes i s either longword (:-)2-bit) or quadword (64 -bit) , DECnet -VAX code that required atomic access to wore! fields had to
be modified to protect aga i nst writes to neighbor ing byte ancl word fields sharing the same long word or quadword . In D ECnet for OpenW,IS AXP,
word data structure fields shared by NETAC:l' and NETDRJVER that required atomic access were moved to their own aligned quadwords to p revent interference from s i m u l ta neous writes to other byte and word fields sharing the same quadword. After the word fields were placed i n their own aligned quadwords, the code generated by the
M.ACR0-32 cross compiler for the ADAW! i nstruction was sufficient to prov ide atomic access to the word fields. We cou ld also have u sed comp iler d i rectives to specify that VAX granu la rity and atom icity rules be preserved.
BL/55-32
Code The lll.ISS-32 code in the DECnet VAX software was relatively s imple to port. We made minor changes to acid the VOLATILE parameter to data i tems that should not be cached i n registers, to cond i t iona l l y com p i le the exception hand lers for VA X or Alpha AXP, and to remove unsupported built-ins. Other modifications were more exten sive , such as the changes to accommodate the new
Ufl$TABLE_PARSE.
% I F % B L I S S ( B L I S S 3 2 V ) % T H E N
L!B$TPARSE
Changes Llfl$TPA RSE and LJB$TAFll.E_ PARSE are the i n terface routines to a general purp ose, table-d riven parser for the OpenVMS VAX ancl OpenVMS A..'\P operating systems, respec tively. The cal l to these rou tines '''as made concli tional fo r the VA X and Alpha A X!' archi tectures. Other changes were requ ired because Ull$TPARSEancl i.IH$'JABJ.E_PARSE d iffer in the way argument l ists are passed . The method u s eel by UBSTPARSE to pass arguments is incompatible with the OpenVMS
AXP caJ i i ng standard . The L! 13$TPARSE action rou tines requ ired mod ification as a result o f t he required change to UBSTABLE_I'ARSE fo r the OpenVYIS AX!' operating system . The LJB$TPARSE
action routines received all or a subset of the argu ment block as parameters. LIBSTA.BLE_I'ARSE passes the add ress of the argu men t block to t l1e action rou t ines. The solut ion we used was to make the rou tine declaration conditiona.l so that on the
OpenVNIS VA X operating system the action rou tines continued to receive the argu ment block parame ters, and on the Open VMS A..'\P operating system the action ro ut ines received the add ress of the argu ment block . Next, for the OpenV.viS A. X l' op erating syste m , the parameter n ames used by the common code were bou n d to the argu ment block. These changes are shown in Figure 5.
As a resu lt of this relatively s imple though repeti tive change, no other changes had to be made in the action rout ines. If at some fu ture time the Open VMS
VAX operating system uses LIB $TABLE_PARSE, there will be no need fo r conditionals.
G L O B A L R O U T I N E A C T $ I N V C O M M A N D ( O P T , S T R C N T , S T R P T R , T K N C N T , T K N P T R , C H R , N U M , P A R A M ) = I % E L S E G L O B A L R O U T I N E A C T $ I N V C O M M A N D ( P A R S E S T A T E : R E F $ B B L O C K ) I % F I % I F % B L I S S ( B L I S S 3 2 E ) % T H E N B I N D % F I O P T S T R C N T S T R P T R T K N C N T T K N P T R C H R N U M P A R A M P A R S E _ S T A T E C T P A $ L_O P T I O N S J , P A R S E _S T A T E [ T P A $ L_ S T R I N G C N T ] , P A R S E _S T A T E [ T P A $ L_ S T R I N G P T R J , P A R S E _S T A T E [ T P A $ L_T O K E N C N T J , P A R S E _S T A T E [ T P A $ L_ T O K E N P T R J , P A R S E _S T A T E [ T P A $ B_ C H A R J , P A R S E_S T A T E [ T P A $ L_ N U M B E R J , P A R S E S T A T E [ T P A $ L P A R A M ]
Figure 5
L!B$ TPAR5E
ChangesConclusion
This porting effort not only provided a solid base of knowledge with which to begi n the port of the DECnet/OSI for OpenVMS VAX software and the associated prod ucts, but a lso gave us an apprecia tion of common code and the avoidance of archi tecture-specific cod e.
More and more software is being po rted to new hardware platforms. The porting process is often carried our by individuals who did not deve lop the original software and who may not even be fam i l iar with it. Our ex pe rience porting the DECnet-VAX code leads us to bel ieve that new soft ware development shou ld take into account the possi bil ity that the code wi l l be ported to new hardware platf<>rms at some future date. As we con tinue to port the DECnet/051 for OpenVM5 VAX soft ware, it is becoming increasingly obv ious that certain coding practices are difficu l t to port. As a general suggestion, if the code has knowledge of the architectu re but can be written using system routines, system services, or run -tim e l i brary func t ions, write the code in that manner. These system rou tines wi l l be ported with the operating system, and in a majority of the cases, the appl ication code will not require modification.
Also, if archi tecture- specific functions are requ ired , provide only a m inimum amount of code to perform these required functions and segregate the code. Document how the code works, why i t had t o be d o n e that way, what t h e al ternatives were, and why they were not taken . In addition to helping maintain the code, this information m ay provide val uable assistance to a person porting the code in the future.
If a rou tine is written in assembly l anguage for the sole purpose of performance i mprovement, consider rew riting it in a h igh-level language. I t is possible that the assembly language coding conven tions that may have been opti mal for one hardware platform w i l l be slower on a different hardware platform . Using h igh- level l anguage compilers, which generate opti mized hardware-specific code, will elim inate additional porting effort and may very likely be the best performance solution.
As we d iscovered during the process of p orting the DECnet -VA X software, MACf{0-32 code is signifi cantly more difficult to port than code writ ten in higher- level languages. However, certain archi tec ture-specific fu nctions m ay have to be written in assembly language. We recommend that these fu nc tions be isolated. In add ition, we recommend that
Digital Technical journal Vol. 4 .Vo. 4 ,\j;ecial fssue 1991