The Compiler System Of ATLAS

C/ATLAS or Common Abbreviated Test Language for All Systems is astandardized test-oriented language for test procedures and test programs. Itis independent of any specific test system and has been widely used in thefield of automatic test on various avionics. Compared to other languages,making programs with ATLAS can get a shorter cycle and a higherefficiency, which makes ATLAS a most popular language in test field. Sofar PAWS developed by TYX Corporation and SMART by ARINCCorporation are classical and mature ATLAS compilers whichconveniently support compiling, editing and debugging ATLAS programson Windows NT operating system, but using them is not a easy workbecause of their complex structure. Furthermore, their high prices preventus from buying and using them freely and then from introducing this usefullanguage to many test programmers in our country. Under this circumstance,we design and implement a compiler system for ATLAS Std. 716-1995.ATLAS language not only defines the general control structure likecommon programming languages, but defines full test statements, whichmakes ATLAS much larger than other languages. The test statements inATLAS language consists mainly of three kinds: signal oriented statements,timing statements and databus statements. Signal oriented statementsinclude single-action, multiple-action and digital statements. Onemultiple-action statement equals functionally to a single-action statementsequence, so from the point of view of implementation, multiple-actionstatements can be easily implemented as long as all single-action ones aredesigned. The compiler mentioned in this thesis includes the followingfunction: lexical analysis, syntax analysis, transformation of all generalstatements and most of signal-oriented and bus statements to C++ language.It can edit, compile and then run basic test programs.The whole ATLAS compiler system, done by a project group, includesATLAS compiler, test environment models and runtime system. In thefollowing issues, parts with "*T" are theoretical contributions finished bythe author independently;Parts with "*R" are implementation worksfinished by the author independently;Parts with "&" are contributions of thewhole project group including the author;Parts without any flag arecontributions by other members without the author's participation.1. ATLAS Compiler(1)*R Design and implement the syntax analysis system of ATLASlanguage. The parser is generated by ACCENT which is an excellent parsergenerator based on Earley parsing algorithm. The reason not using YACC orBISON but ACCENT is that the converted ATLAS grammar contains toomany S/R or R/R conflicts, and the conflicts can not be eliminated in someformal technique. The only way is to find and remove them according toexperiences, but this is a rather hard work because of the large size of thegrammar. Compared to other parser generators, ACCENT can work on allcontext-free grammars and output a parser because it is based on Earleyparsing which can work on all CFGs.(2)*T Propose several transformation algorithms from ATLASprecedence grammar to BNF and a kind of Earley parsing technique forextended grammars. IEEE introduced a special kind of EBNF notation inthe definition of ATLAS. Normal EBNF only introduces several extendedoperators (for instance star closure) on the basis of BNF in the right-handside of BNF productions. However, ATLAS not only introduces theseoperators but also defines the precedence between them, which makesgrammars look simpler and more compact. Language definers never thoughthow to design the corresponding syntax parser. One way is to transformATLAS grammar to equivalent BNF form. This thesis suggests severalconversion algorithms. Another method is to design a parser directly on thisspecial grammar. The thesis also gives a method of parsing techniquewithout regard to the precedence (namely, the computation order of eachoperator has been assumed to be decided by parentheses).(3)*T Improve ACCENT. Parsers generated by original ACCENT canonly report one error once, which is inconvenient to use. The improvedACCENT can generate parsers which can report multiple syntax errors.According to the fact of having apparent end flag ('$') in all ATLASstatements, parsers can decide whether or not a statement reaches an end. Ifcurrent statement ends with no syntax error, the corresponding current stateswill be stored, otherwise report error information, skip current statement, setlast stored state as current state, and then continue parsing. However, themethod has a limitation, namely when error statement is a key statement,the parser will report a lot of disguised errors. The solution is to limit theerror count.(4) *T, & Present a method of solving the problem on device allocationof ATLAS system using directed graph. ATLAS programs can be run on anyspecific ATE system which consists of various test instruments. These testinstruments connects with outside UUT (Unit Under Test) via matrixes andswitches. What kind of data should we use to express the connectionbetween UUT and instruments? How can we find a proper instrument inATE system to start a test? Above two points are essential questions towhich each ATLAS compiler must face. This thesis proposes that the wholetest system should be abstracted to a directed graph. Thus in a ATE system,all ports or pins of instruments and matrixes can be seen as vertexes of thegraph, whereas connections between these ports or pins can be seen asedges. So using graph traverse algorithm, we can finish device allocationrequirements in a test program.(5) Implement semantic analysis of ATLAS language. Semanticanalysis includes common statement analysis and test procedure analysis.Test statement semantics is classified into two kinds: static and dynamic.Static semantics checking is performed and finished during compilationsuch as checking the match of a verb and a noun, a noun and a modifier.Dynamic semantics checking starts only when a test program is runningsuch as checking the sequence of several single-action statements.(6)& Adopt the form of class as intermediate expression of ATLASprogram. The reason using class is that each test statement of ATLAS has afull and independent structure. We use a member pointer to expresssubordinate object of some class, so if the object pointer of top class isgiven, we can find any syntactical object along the member pointer chain.(7)& Code generation. Implement all common statements and most ofsingle-action, multiple-action and databus statements. This is the mostimportant and difficult work in the whole project. The main idea is to usetransformation technique converting all test statements of ATLAS programto driver functions of instruments, and then loading corresponding librariesduring their execution.(8)*T Give a descriptive model of operational semantic based onabstract machine for single-action statements. In terms of the description,we can clearly understand the function of each single-action statement andthe mutual relationship between them. Furthermore, an implement programof single-action statements can be easily made according to the operationalsemantic because the semantic is based on abstract machine. This thesisonly describes single-action statements. Semantic for bus statements isn'tsupported due to its complex timing. However, a full formal semantic ofATLAS test statements is significative for language implementation, so it isexpected that this part can be perfected in the future.2.& Test Environment ModelsIn order to execute a test program, a concrete test environment isrequired. However, a compiler can not know how a test system isconfigured unless a description is provided. This description is called testenvironment description (TED), and the language used to describe TED iscalled test environment description language (TEDL). We design fourdescription languages: adapter language, switch language, device languageand bus language which describe the whole configuration of a testenvironment. According these descriptions, a test program can get necessarydevices and connections.3. Runtime systemA runtime system is a platform that is responsible for program runningand information management. The run function not only starts a testprogram and runs it, but also provides pause, showing running informationand measurement information. Information management concerns thoseauxiliary test information including test name, test function, programmer,UUT information and so on. These information help testers quickly knowthe basic state of a test.The three parts introduced above makeup the whole ATLAS compilersystem. At the present time, the project has been accomplished two stages.Most of statements are implemented. Now the compiler can compiler somebasic test procedures and the executive file can also be run on practical ATEsystem. A full and practical ATLAS compiler is important on introducingATLAS to test programmers and on realizing test automatization in ourcountry. So in the future, we should perfect the system according topractical applications.