WO2004036421A2

WO2004036421A2 - System and method for a mixed-language compiler

Info

Publication number: WO2004036421A2
Application number: PCT/IL2003/000851
Authority: WO
Inventors: Eitan Glotman
Original assignee: Eitan Glotman
Priority date: 2002-10-21
Filing date: 2003-10-20
Publication date: 2004-04-29
Also published as: WO2004036421A3; AU2003274644A1; AU2003274644A8

Abstract

An executable output program encoded in a first program language is generated from a mixed-language program combining expressions of the first program language and a second program language. The mixed-language program comprises information, that allows conversion of the second program language to the first program language, according to the set of pre-determined rules. The method and system further comprise a set of processing and testing mechanisms for validating the output program language.

Description

SYSTEM AND METHOD FOR A MIXED-LANGUAGE COMPILER

FIELD OF THE INVENTION

The present invention relates to the field of software development, and more particularly, to a computer system and method for a mixed-language compiler, software code optimization and improved program implementation.

BACKGROUND

The development of software (SW) for a computer processor is achieved in stages and involves two languages selection options: The first option is writing the SW in high-level (HL) language, and then the HL program is translated to a low-level (LL) language program by a compiler, thereby producing the processor object file (machine command file). The next stage is testing the program on a processor using a simulated environment, i.e. by a simulator, and then testing the program in a real life environment, i.e. by an emulator. The second option is writing the SW in LL language, translating the SW to the processor object file (machine command file), and then testing the program by both simulator and emulator.

Therefore, in SW implementation for- a processor, which may be digital signal processor (DSP), controller processor or other, a selection has to be made whether to use a HL or LL language for the programming, where each has advantages and disadvantages.

The advantage of a high-level language is short development time, since programming in HL language is easier. Moreover, the implemented algorithm may be developed and tested on a HL language development tool like Visual C. The HL language code produced is also clear and easy for maintenance and modification.

These advantages may be crucial in projects wherein the time to market, and SW maintenance and modification are very important. The disadvantage of programming in HL language is that the resulting code requires considerable resources, such as ROM and MIPS, from the processor's environment, and therefore increases product cost.

On the other hand, coding in low-level language may result in minimum resources, which may be important for products that are sold in large quantities, e.g. in the communication field. But LL programming requires long development time and an arduous SW debugging process. The SW code produced is not clear, even for the programmer. It may include hidden bugs, and be difficult to modify and maintain.

The disadvantages multiply as more options and functions are added to projects. Conversely, mass production introduces savings in the manufacture phase, thereby reducing silicon size, MIPS and power consumption and may enable reduced prices.

One option to enjoy the advantages of the two coding methods, HL and LL language programming, is to write the SW in HL language and translate it to LL language using optimizers, but unfortunately the optimizer performance available today is limited, and the LL code produced is not close enough to the code written initially in

LL language.

Therefore a need exists for a system and method for use in SW development of processors, having low cost resource consumption and low cost development, modification and maintenance of the code.

SUMMARY OF THE INVENTION

Accordingly, it is a principal object of the present invention to overcome the disadvantages of the prior art systems, and to provide a system and method for SW implementation for a processing unit, such that resource consumption is low, development time is short and the software is clearly understandable, and which is easy to maintain and modify.

It is a further object of the present invention to simplify and improve the translation process of one program to another program. It is a further object of the present invention to implement a high-level language program, which describes a mathematical algorithm or other form of software based, on a Mixed Language program, i.e. both high-level and low-level.

It is another object of the present invention to provide a Mixed Language, which specifies to the compiler the low-level language commands and the hardware modules to be used for each high-level instruction expression. Thus, software optimization is performed by hand, but the basic structure of clear, high-level language program commands and flow are intact.

A computer-implemented method is disclosed for generating a program in a first language compilable to run on a predetermined processor from a mixed-language program combining expressions of said first program language and a second program language. The method comprises receiving as input the mixed-language program, that allows generation of a first program language according to a set of pre-determined rules, as will be explained in detail hereinafter; and generating an executable output program encoded in said first language.

In a further embodiment the mixed-language program language comprises information, that allows conversion of the second program language to the first program language, according to the a set of pre-determined rules.

In one embodiment of the method according to the present invention, the first language is low-level and instructions encoded in said first language are presented in structured algebraic form.

In a preferred embodiment the method according to the present invention further includes generating from the mixed-language program at least one of the following additional output files:

(a) first output program file encoded in said first program language;

(b) second program output file encoded in the second program language;

(c) first output file encoded in the structured algebraic form;

(d) Mixed language list file; and (e) Any combination of two or more of (a) to (d).

The method according to the present invention further involves displaying the mixed language program in at least one of a given set of display modes, as will be explained in detail hereinafter.

In a further embodiment either the first output program language is executed, or the second program language expressions are executed, or both the first output program and the second program language expressions are executed.

In a preferred embodiment, wherein both the first output program and the second program language expressions are executed, the method further includes processing, examination, execution, or any combination thereof, of the first program language and the second program language expressions so as to indicate an error or any lack of equivalence between the first program language and the second program language, and, if an error or an un- equivalence occurs, an error detection report is outputted.

In a preferred embodiment, the method further includes validating that the mixed language program expressions are formulated correctly.

The mixed-language program is generated either from an input program encoded in the second program language, or is created directly in mixed-language code, i.e. without an input reference file encoded in a second language. The creation of the mixed-language code is done, for example, through a mixed-language editor. In a preferred embodiment, wherein a second output program language file, which is reproduced by the mixed language compiler, is outputted, a validation that the second output program language is functionally equivalent to said input program, is performed. In further embodiments said validation includes: generating a second output program encoded in said second program language; feeding an input test vector to both the input program and to the second output program; and comparing an output test vector of the second output program to an output test vector of the input program, or generating second output program code encoded in said second program language; and comparing the code text of the second output program to the code text of the input program. It is to be understood that the method according to the present invention may be carried out either when the mixed-language program expressions represent a complete program, or a part of a program.

In a further embodiment the method according to the present invention includes generating and editing said mixed-language program expressions; and translating each mixed-language expression to first and second language expressions immediately after it is written and/or performing errors detection, as describe in the section 'Compiler

Error Detection'.

In the scope of the present invention is also a system for generating a program in a first language compilable to run on a predetermined processor, from a mixed- language program combining expressions of said first language and a second program language. The system comprises a mixed language compiler for receiving mixed- language program expressions of a second program language and the first program language that allows generation of a first program language according to a set of predetermined rules, and generates an executable output program encoded in said first language. - .

In further embodiments the mixed-language program language comprises information, that allows the mixed-language compiler to convert the second program language to the first program language, according to the set of pre-determined rules, as will be explained in detail hereinafter. In a preferred embodiment, the first language is low-level, the mixed-language program expressions contain information relating to resources required by said predetermined processor in order to execute the expressions in the first language, and the system includes a compiler adapted to analyze the mixed language program expressions in order to extract said resources therefrom and produce the first program language, according to a set of pre determined rules.

In a further embodiment the system is adapted to validate that the mixed language program expressions are formulated correctly. In a preferred embodiment the system is further adapted to generate the mixed language program from an input program encoded in the second program language.

In a further embodiment the system also comprises: a compiler for generating a second output program encoded in said second program language; and a comparator for comparing an output test vector of the second output program to an output test vector of the input program in response to an input test vector fed to both the input program and to the second output program, or a compiler for generating second output program code encoded in said second program language; and a comparator for comparing code of the second output program to code of the input program.

In one embodiment of the system according to the present invention, the first language is low-level and instructions encoded in said first language are presented in structured algebraic form.

In a preferred embodiment the mixed-language compiler processes the mixed language program according to a set of predetermined rules and generates at least one of the following additional output files: (a) first output program code encoded in said first program language;

(b) second output program code encoded in said second program language;

(c) first output file encoded in the structured algebraic form;

(d) mixed language list file; and

(e) any combination of two or more of (a) to (d). In a further embodiment, the mixed-language compiler processes said mixed- language program so as to indicate an error or any lack of equivalence between the first program language and the second program language, such as errors detection, and, if an error or an un-equivalence occurs, outputs an error detection report.

In another embodiment, the processing of the first output program or the second output program by the mixed-language compiler,. It is to be understood that said test or tests may be performed by the mixed- language compiler on a complete output program file or any part of it.

In a further embodiment, the system further comprises a mixed-language simulator for processing and testing said mixed-language program.

The mixed-language simulator may be further adapted to display the mixed- language program in at least one of a given set of display modes, as will be explained in detail hereinafter.

In one embodiment the first language is low-level, and the mixed-language simulator displays the first program language in structured algebraic form.

In a further embodiment the mixed-language simulator is adapted to execute either the first program language or a second program language, or both.

In a preferred embodiment, wherein both the first output program and the second program language expressions are executed, the simulator is further adapted to perform an error test and/or equivalency check between the first program language expressions and the program encoded in the second language, and to output an error detection report if an error or an un-equivalency occurs, as will be further described hereinafter.

In another embodiment, the mixed-language simulator is adapted to process and test of the first program language and/or the second program language.

It is to be understood that said testing may be performed by the mixed-language simulator on a complete output program file or any part of it.

In a further embodiment the system also comprises a mixed-language emulator for processing and testing said mixed-language program. The mixed-language emulator may be further adapted to display the mixed- language program in at least one of a given set of display modes, as will be explained in detail hereinafter.

In one embodiment the first language is low-level, and the mixed-language emulator displays the first program language in structured algebraic form. In a further embodiment the mixed-language emulator is adapted to execute either the first program language or a second program language, or both. In a preferred embodiment, wherein both the first output program and the second program language expressions are executed, the emulator is further adapted to perform an equivalency check between the first program language expressions and the program encoded in the second language, and to output an error detection report if un- equivalency occurs.

In another embodiment, the mixed-language emulator is adapted to process and test of the first program language and/or the second program language.

It is to be understood that said test or tests may be performed by the mixed- language emulator on a complete output program file or any part of it. In a further embodiment the system also comprises an editor adapted to generate the mixed-language program through translation of each mixed-language expression immediately after it is written and to perform errors detection as will be described hereinafter.

Additional features and advantages of the invention will become apparent from the following drawings and description.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the invention and to see how it may be carried out in practice, some preferred embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:

Fig. 1 is a flow chart of the method for an input algorithm written in high-level language, such as C/C++, constructed in accordance with the principles of the present invention;

Fig. 2 is a general flow chart for implementation of a Mixed Language program written directly in the Mixed Language syntax, constructed in accordance with the principles of the present invention; Fig. 3 is a schematic block diagram of the ML system development tool for use with a program translated by the compiler to LL language and machine code and tested by ML simulator and ML emulator, constructed in accordance with the principles of the present invention.

Fig. 4 is a schematic block diagram chart illustrating equivalency validation of the source HL program and the compiler reconstructed HL program output presented in Fig. 1 block 160, constructed in accordance with the principles of the present invention;

Fig. 5 is a flow chart of a variable reference test to check for errors in the LL program variables declaration, constructed in accordance with the principles of the present invention;

Fig. 6 is a screen shot illustration of ML simulator and emulator display options including Algebraic and Mixed, High-Level and Low-Level Language Windows, constructed in accordance with the principles of the present invention; and

Fig. 7 is a screen shot illustration of ML simulator and emulator showing a 'Mix Window', that presents two, three or four of the display modes of Fig. 6 in one window, constructed in accordance with the principles of the present invention.

Fig. 8 is a schematic block diagram of a ML system development tool, constructed in accordance with the principles of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The principles and execution of a method according to the present invention, and the operation and properties of a system described thereby may be understood with reference to the drawings and the accompanying description of non-limiting, exemplary embodiments.

It is to be understood that the terms HL and LL are used hereinafter merely as illustrative, non-limiting examples, and that the method and system in accordance with the present invention apply for any first program language and any second program language.

1.1 General Description The Mixed Language method aim is to produce optimal code for processing unit, which reduce resources and manufacture prices, maintaining clear code and flow in order to reduce development, maintenance and modification costs. The Mixed Language (ML) programming method achieves this.

The Mixed Language method is based on the regular high-level language syntax added with the low-level language commands and operands in their various forms such as the processing unit low-level syntax, simulated low-level expression syntax etc. . This way the program optimization is done by hand producing optimized and friendly code. The method is composed form a number of stages and the development tools that are used are the common development tools with modifications.

Fig. 1 is a flow chart of the method for an input algorithm written in high-level language, like C/C++, constructed in accordance with the principles of the present invention. The starting point may be a special algorithm 100 written in C, or other high-level language, fixed point or floating point, according to the processor that is being used. First modification is made to mixed language 110 , by adding to the high level language program a target processor low level language commands and resources. Optionally using a special editor which translates each written ML command line, immediately after it is written.

Fig. 2 is a general flow chart for implementation of a Mixed Language program written directly in the Mixed Language syntax, constructed in accordance with the principles of the present invention. The starting point is an input algorithm 200, which may be some general algorithm or software flow, which has to be implemented in the system.

For both Fig. 1 and Fig. 2 the second step is the production of Mixed Language program which consists of Mixed high and low level program expressions, and composed of the High-level program and target processor low level language (like assembler) and hardware modules. This mixed language program is compiled, as shown in reference blocks 120 and 220, respectively. The Mixed Language main function defines to the compiler the LL operands and commands, such as which register to use in each high-level line of code, what variable it represents and what LL command to use. For example the high-level language line of code is:

Var = 0; (hi)

Var0 = Var0+100; (h2) |<!use addm>| // addm is a TI assembler command

In the Mixed Language 'Var' is assign to register 'a' thus the new command line is:

|{var}||<a>| = 0; (ml)

Var0 = Var0+100; (m2) |<!use addm>| // addm is a TI assembler command

which specifies to the compiler that register 'a' represents the variable 'var', and expression (m2) defines to use the assembler 'addm' command that cause the variable 'varO' to be directly incremented with 100.

The rules for the Mixed Language syntax are detailed in Section 1.8, where more examples can be found.

For both Fig. 1 and Fig. 2 the third step is the compilation of the Mixed Language program in order to translate it to an object file and prepare it to run on the simulator and on the target processor, as shown in reference blocks 130 and 230, respectively. The compiler converts the Mixed Language program into Mixed Language Program list file, Low-level language program (like assembler file), High- level language program (like C file), Algebraic language program and Code Object file which can loaded and run on the target processing unit (like DSP or embedded). Then the compiler outputs these files, to be used by the simulator and emulator. In addition the compiler may detect errors in the Mixed Language program by comparing the parameters and variables of the low-level to the high-level programs, such as, wrong use of registers. The fourth step is testing and debugging the program with the Mixed Language simulator, which may be similar to general simulators used in implementation of software on the processor, for example a DSP, a micro-controller etc., as shown in reference blocks 140 and 240, respectively. In addition to the common features of the simulator, the Mixed Language simulator has special features such as automatic Mixed Language program error detection that may also execute the HL program, and a user- friendly program multi mode display of the tested code which may have a number of display modes such as the Mixed Language program, the high-level program, the algebraic code, the low-level program, or any mixture of display modes.

The next step is the Mixed Language emulator, which enables testing of the implemented program in the 'real-time' environment, performing Automatic Mixed- language program errors detection and enables the Multi mode display of the tested code as shown in reference blocks 150 and 250, respectively.

The method of Fig. 1 has a further step, i.e. the ability to perform high-level program equivalency validation in order to check that the modification of high level to Mixed language was performed properly and no error occured in this stage 160. This is done by comparison between the source algorithm 100 and the compiler HL output program extracted and reproduced from the ML program, and is detailed hereinbelow in Fig. 4.

In the method of Fig 2, testing on high-level environment development tool 260, may be performed by testing the reproduced high-level language program on a high- level development tool, such as Visual C or other.

The features of the Mixed Language emulator are similar to general emulators used in implementation of software on processors, such as a DSP, micro-controller etc., except that the emulator has special features, which are similar to the Mixed Language simulator, such as automatic SW error detection, that may also execute the HL program, and a user-friendly Mixed Language program display, which may have number of display modes like the Mixed Language program, the high-level program, the algebraic code and the low-level program, or any mixture of display modes. Thus, the described method enables fast implementation, with automatic-error detection, low resource consumption and clearly understandable, easily modified and maintenance.

Fig. 3 is a schematic block diagram of the ML system development tool 300 for use with a program translated by the compiler to LL language and machine code, constructed in accordance with the principles of the present invention. The ML system development tool 300, shown in Fig. 3, is similar to general processor development tools. It begins with a ML program 310 that is translated by the ML compiler 320 to LL language and machine code. The compiler output is fed to ML simulator 330 that tests the program in a simulated environment of the processor by means of a simulated processor 335, with access to the simulated processor internal registers 336 and to the processors simulated memory 337. Another test of the program is performed in the 'real life' environment by the ML emulator 340 that is connected to the 345 processor and has access to the processor environment like the processor internal registers 346 and to the processors memory 347. The difference between the general processor development tools and ML development tool 300 that is that the ML development tools (300) are adapted to the ML features - described below.

Fig. 8 is a schematic block diagram of the ML system development tool, constructed in accordance with the principles of the present invention. The ML system development tool includes an editor 820 that produces the mixed language program from an Input

SW flow 810, which may be either a program written directly in the mixed language, or an Input Program File, optionally written in HL language such as C language. The result mixed-language program file is then processed by a compiler 840, a simulator 850, an emulator 860 and a comparator 865, all used to output a Second output

Program file 870, optionally a HL language program file such as C language, a First output Program file 880, optionally LL language program file such as assembly or micro-coding language, a First output executable program 885 which may be loaded and run on the target predetermined processor, and an Errors Message unit 890 that is used to output the error messages of the system according to the present invention, such as lack of equivalence between the first output program and the second output program. Fig. 4 is a schematic block diagram chart illustrating equivalency validation 400 of the method presented in Fig. 1, where a comparison is performed between the source HL program and the compiler's reconstructed HL program output from the ML program, constructed in accordance with the principles of the present invention. The difference between the two methods, described in Figs. 1 and 2, is in the steps used to produce the Mixed Level language program and in the ability to equivalency check the ML program to the source algorithm, which is done by comparison of the source HL algorithm program 412 to the HL program 411 reproduced from the ML program by the compiler, presented in Fig. 4. The equivalency checks have two comparison options. The first is comparison 410 of the text expressions of the two programs, and the second equivalency checks option is a test vectors comparison 440, which is done by compiling the two programs 421 and 422, respectively, and testing the executable files produced in steps 431 and 432, respectively, by use of test vectors data 445.

The above-described steps will now be described in more detail.

1.2 Input Program/Algorithm

Implementation of the program on the target processor may start with a 'closed' mathematical algorithm, such as MPEG, or with a general SW flow with no previous reference. In the first case, described in Fig. 1, the input algorithm is written in a high- level language, like C, which was used for development and testing. Before implementation, it is preferable to assure that the calculation in the algorithm conforms to the target processor type, floating point or fixed point.

The second case, described in Fig. 2, represents a general program flow to be implemented. In this case the Mixed Language will be written directly in the Mixed Language syntax.

1.3 Conversion to Mixed Language

The conversion to Mixed Language program main idea is defining to the compiler the exact reference to the processor's low-level language and hardware resources (like registers and ALU operation) in each high-level language expression.

This is done by specifying to the source high-level program or the new program, the exact low-level language command and resources (like registers). Consideration is preferably given to the low-level language commands, the use of the registers, the order of calculation, and especially in the translation of the Mixed Level program to low- level language program. The rules and syntax of the Mixed Language are presented in section 1.8.

On the Mixed Language example below the high-level language line is:

temp_var = 1 ;

thereby specifying that the temporary variable 'temp_var' is loaded with the value 1. Lets it is assumed that 'temp_var' is used only right after this line, and it is not defined in the LL program and therefore is not allocated to a memory cell. Thus register

'a' may be assigned to represent 'temp_var',and the Mixed Language new command line is:

|{temp_var}||<a>| = 0;

Which specifies that register 'a' is to be loaded with the value T. It also specifies in advance that until a new assignment is made, register 'a' is assigned to the variable 'temp_var'.

Consideration is preferably given to the low-level language commands, the use of the registers, the order of calculation and, especially to the translation of the Mixed Level program to low-level language program. Thus, it is preferable to use a mixed- language editor, which: translates each written ML command line, immediately after it is written, and displays the translation in a separate window as presented in figure 7 and described in section 'Program display options', and therefore enables to verify the LL expression produced by the ML expression; and performs the compiler error correction of the written code as described in section 1.4.3.

More ML rules and examples are presented in section 1.8. 1.4 Mixed Language Compiler Development Tool

The ML compiler operation is based on the ML syntax rules presented in section 1.8, and according to those rules the Mixed Language program is processed by the Mixed Language compiler translating the ML program into low-level language program. The ML compiler properties and outputs are similar to the common compiler, for example the translation to low-level language program, produce the object code file and prepare the input files for the development tools. The addition properties and outputs of the ML compiler are:

high-level program extracted from the ML program;

produce a Mixed Language program list file which contains;

the source ML expressions;

the extracted high-level operations;

the algebraic presentation of the ML expressions; and

the low-level commands; and

error detection of the interlacing of the low-level commands, parameters and registers in the Mixed Language software.

The main difference of the Mixed Language compiler from common compiler is that the Mixed Language compiler input file (the ML program) includes most of the optimization information performed by the common compiler (like LL operands and commands allocation in the LL program). The result is that the Mixed Language program produce optimized low-level language program, while the conventional compilers optimization performance is limited.

1.4.1 Production of the High-Level program

The Mixed Language compiler may output the high-level language program that is extracted from the Mixed Language program by elimination of all low-level parts of the program. The elimination is done according to the ML rules, presented in section 1.8. For example the ML expression:

|<{Var1}=a>| = |<a{=var2}>|+var3;

The HL expression extraction is done in the following stages:

The HL extraction of the expression |<a{=var2}>| is performed by elimination of all LL expression and the association sings: e.g. '|<a{= }>| thus Var2 is remained. The Var3' is not surrounded with no bracket thus it is common to the HL and LL expression. Therefore the result HL expression of the right side of the expression is:

= var2 + var3

The left side of the ML expression is: '|<{Var1}^:=a>|' and after elimination of the

LL expressions and association sings: eg. |<{ }=a>| then the expression remained is 'varl'.

The next stage is gather the above stages to get the extracted HL expression:

Var1 = var2 + var3;

More examples are presented in section 1.8 'Mixed Language Rules'.

The aim of the extracted high-level program is:

1) View the Mixed Language program in its high-level language mode, thus simplify the understanding, debugging and modification of the code.

This view mode of the program may be available on:

i, A separate program file

ii. The high-level instructions are included in the output list file which may be used to observe the Mixed Language compiler operation. iii. The Simulator or Emulator environment. View the high- level language part of the Mixed Language program may simplify the debugging.

2) If the implementation of the code started from a reference code, ^' like a mathematical algorithm or standard (like the ITU's G.726 standard or any

IP algorithm) then the extracted high-level program behavior may be compared with the original algorithm behavior in order to verify that the ML high-level program operation is similar or identical to the original source algorithm, presented in Fig. 4. The equivalency checks, presented in the figure, has two comparison options: The first is comparison the text expressions of the two programs, and the second equivalency checks option is a test vectors comparison, which is done by compiling the two programs and test the executable files by test vectors.

3) If the implementation of the code was not started from a reference code, then the high-level language part of the Mixed Language program may be checked by running it on the specific high-level debugging tool (such as Visual C) or by running the 'exe' program, after compilation and linking, and thus performing a test vector check.

4) Find errors in the Mixed Language program by comparison the HL expressions to the ML, LL and algebraic expressions.

1.4.2 Mixed Language program list file

The ML list file may include for each ML operation the following:

mixed Language operation;

the extracted high-level operation;

the algebraic presentation of the instruction; and

the low-levei translation. This file may be used for example to observe the operation of compilation process, and it may be used by the ML simulator and ML emulator to display the program in the selected display mode - the ML program, the high-level program, the algebraic presentation and the low-level program.

The extraction of the list file is performed according to the ML syntax rules presented in section 1.8. Each ML operation command line is analyzed, and according to the ML rules the following are produced: the source ML expression; the extracted high-level operation; the algebraic operation; and the low-level operation, where every line has a prefix according to the language it represents: ML, HL, AL and LL respectively. In the next step the low-level operations together produce the low-level program that is processed (assembled) to in turn produce a coefficient object file that can be executed by the processor.

Example 1:

The high-level language line is:

temp_var = 1;

and the Mixed Language line is:

|{temp_var}||<a>! = 1;

Where as described in paragraph 1.3, 'temp_var' is temporary and register 'a' is ssign to represent it.

For the above example the compiler output files may be:

high-level language file includes command lines like: temp_var=1 ;

low-level (assembly) language file includes command lines like: Id #1, a

the algebraic code file representation of this line: a = 1

Mixed-language list file may include the four display modes for each command line, like: ML: |{ temp_var}||<a>| = 1 ;

HL: temp__var=1;

AL: a = 1;

AS: Id #1, a

Example 2:

The high-level language command sequence:

varl = 1 ; (hi)// load varl

*pnt1 = *pnt1*2 + varl + var2; (h2)//calculate ^*pnt1

May produce the following translation to Mixed Language:

|<{Var1}b >| = 1 ; (ml) // load varl

|<ar1 = pnt1>|; (m2) // ar1 is address pointer register

|<{*pnt1=}*ar1 =a>j = ]<a=*ar1{=*pnt1}>| * 2 + |<b{var1}>| + var2;

(m3)

The reproduced high-level language command sequence, which is similar to the original HL sequence:

Varl = 1 ; // result of line (ml )

*pnt1 = *pnt1 *2 +var1 + var2; // result of line (m3)

The algebraic command sequence (AL):

b = 1; (a1) ar1 = pntl ; (a2)

a=*ar1«1 ; (a3)

a = a + b ;

a = a + var2;

*ar1 = a;

The low-level command sequence:

Ld #1,b //Var1 = 1 .result of (a1)

Mvdm pntl , ar1 //ar1=pnt1 , result of (a2)

Ld *ar1,1 ,a // a= (a=*ar1) * 2 , result of (a3)

Add b, a //.a = (a=*ar1) * 2 + varl, result of

(a3)

Add var2, a // |<a>| = (a=*ar1) * 2 + varl + var2, result of (a3)

Stl a, *ar1 //|<{*pnt1=}*ar1 =a>| =

// |<a=*ar1{=*pnt1}>| * 2 + varl

+ var2

Mixed-language list file:

ML:|<{Var1}=b>| = 1; // load varl

HL: var = 1;

AL:b=1; AS: Ld #1, b

ML:|<ar1 = pnt1>|; // ah is address pointer register

AL:ar1 = pntl ;

AS: Mvdm pntl , ar1

ML:|<fpnt1=}*ar1 =a>| = |<a=*ar1{=*pnt1}>| * 2 + varl + var2;

HL: *pnt1 = *pnt1*2 + varl + var2;

AL: a=^*ar1«1 ; (a3)

AL: a = a + b ;

AL: a = a + var2;

AL: *ar1 = a;

AS: Ld *ar1 , 1 , a // a= (a=*ar1) * 2 , result of (a3)

AS: Add b, a // a = (a=*ar1) * 2 + varl , result of

(a3)

AS: Add var2, a // |<a>| = (a=*ar1) * 2 + varl + var2, result of (a3)

AS: Stl a, *ar1 // |<{*pnt1=}*ar1 =a>| =

// |<a=*ar1 {=^*pnt1 }>| * 2 + varl + var2 1.4.2.1 Algebraic Code

The algebraic (AL) code is the ML code presented in the LL commands algebraic code, but it maintains the HL structure of the program.

The translation from ML code to AL code is performed according to the following:

Regular mathematical expressions such as add, multiply are translated to LL commands and are presented in an algebraic presentation.

For example: The ML expression:

|{var1}||| = |<b={var}>|+1 ; is translated to AL code: b=var; b= b+1 ;

Expressions having internal calculations, e.g. 'if, calls to routines, etc:

The call to routine may include calculation inside the parentheses, in this case the Algebraic commands will be included in the routine calling command.

For example the ML calling expression

|<{Var1}=reg1>| = subroutine_name(|<a={var2}>|+1,..,|<b{=var3}>|...);

will be translated to the Algebraic code as: regl = subroutine_name((a=var2, a = a+1),..,reg3,...); Var1=reg1;

The first parameter is prepared in the calling routine line. More examples are presented in the ML rules in section 1.8, hereinbelow.

LL command may be included as:

jasm: LL_command>| There may be commands wherein the ML format is copied to the AL code presentation, these command are included in the ML rules section 1.8, hereinbelow

1.4.3 Compiler Error Detection

In addition the Mixed Language compiler has an errors detection capability.

Except the syntax errors detection the Mixed Language compiler may detects errors in the Mixed Language program, errors of un-equivalency between the low-level and the high-level language operands. For example, if the compiler detects a register that represents a certain variable that is expected to represent, or to be equal to, another variable, then an error message may be produced including error details and error location. The following ML operation describes this test:

|{var1}||<a>| = 1;

|<{var3}=a>| = |<a{var1}>| * 2;

On this example register 'a', which is represent 'varl', is loaded by '1', and then in the second line the expression '|<a{var1}>|' defines that it is expected that register 'a' represents Var . The next step is multiplying register 'a' by two and moved to var3.

If the Mixed Language program is: .

|{var1}||<a>| = 1;

|<{var3}=a>| = |<a{var2}>| * 2;

The compiler may detect that in the first line register 'a' is assign to represent

'varl', but in the second line the syntax '|<a{var2}>|' interpretation is that Var2' is represented by register 'a', which contradicts the first line and error message may be produced.

The implementation of the errors detection may be performed by filling an Association Table (described below) that specifies the representation and connection between the high-level or low-level program variables and the low-level HW resource - registers. This table include the information of the register name (e.g. register a, b, ar1 etc.), the name of the variable it is associated to, the association type that may be value or pointer.

When an expression result is written from register to variable or from variable to register, then the table is filled with the specific register, the specific variable name and the type of the association e.g. value or pointer. In additional, if the variable was assigned previously to another register, and the association type is value then the association of that register is cleared.

If a copy between two registers is perform then according to the copy operation the association of the destination register is updated. For example the case of copy 'regl = reg2', in which case the association of Yeg2' is copied to the association of 'regl', or if 'reg1=*pntr_reg' and 'pntr_reg' is associated to 'varl' with association type of pointer, then regl association in the association table is filled with the variable VarT and the association type is value.

On the other direction, the association test, on any operation that assumes that a register is associated with a certain variable then the association is checked in the Association Table and if a contradictory found then an error message is produced.

The association type - value or pointer is set according to the assignment type. If a register gets the value of variable or a constant then the 'association type' is 'value', and if the register gets the address of a variable then the 'association type' is 'pointer'.

For example, the expression:

Short varl; |< {var1}=b>| = 100;

then the Association Table is filled with the following:

And when the expression:

|< b{=var1}>|

is found then the compiler check that register 'b' is associated with the variable 'varl ', and the association type is 'value'.

An example for error is the following:

|< b{=var2}>)

this statement expects that register ,'b' will represent Var2' but this contradict the Association Table information where it is specified that register 'b' represents 'varl ', thus an error message will be produced.

Example 2:

Consider the following High-level sequence:

Var3 = var4«2; // var3 = var4*(2^Λ2)

Var5 = array[0]+100;

Varl = var3+array[1]+3;

The Mix Language: |<{Var3}a>|= var4«2; (ml)

|<ar1 = &array[0]>|; (m2)

|<{Var5}= b>| = |<b=*ar1+{= array[0]}>|+100; (m3)

={Var1}=a>| = |<b{var3}>| + |<*ar1{=array[1]}>| + 3;(m4)

|<{var5}=a>| = |<*ar1{= array[1]}>| « 2; (m5)

Note for the error in (m4) expression '|<b{var3}>|

Compiler error detection process:

Note that the new information is in New (italic bold underline).

After (ml) the Association Table is updated with Var3' represented by register

(m2) updates that ar1 point to array[0]:

On (m3) the expression: *ar1+{= array[0]} causes the compiler to verify that ar1 points to 'array', Then register 'b' is loaded with the value of '*ar1' which equals to array[0] thus the Association Table is updated with: ^■

Next the result is stored register 'b' and then. in Var5' therefore varδ is marked to represented by register 'b', thus after updating the Association Table will contain:

The (m4) ML expression: |<{Var1}=a>| = |<b{var3}>| + |<*ar1{=array[1]}>| + 3

The expression '|<b{var3}>|' implies that register 'b' is expected to represents 'var3', but according the Association Table register 'b' represents 'var5', thus there is an error in the ML (m4) expression, and error message may be reported concerning the error location and error details.

If (m4) is corrected:

|<{Var1}=a>| = |<a{var3}>| + |<*ar1{=array[1]}>| + 3; (m4 corrected)

Then the expression '|<a{var3}>|' implies that register 'a' is expected to represents Var3' ,which is true according to the Association Table. Next the expression

'|<^*ar1{=array[1]}>|' implies that ar1 points to 'array' buffer, which agree with the Association Table. After the addition of *ar1 and '3' to register 'a' then the result is stored in 'varl ' and the Association Table is updated:

The (m5) expression:

|<{var5}=a>| = |<a=*art {= array[1 ]}>| « 2; (mδ)

The expression '|<*ar1{= array[1]}>|' is examined and checked that 'art represents 'array'. After register 'a' is loaded with the content of '*ar1' and shift by two, the result is moved to 'varδ' and the association table is updated with the association between register 'a' and 'varδ', and in addition the association between register 'b' and 'varδ' is cleared, that is since register 'b' is no longer represents 'varδ'.

1.δ Mixed Language Simulator Development Tool

The Mixed Language simulator, similarly to general simulators used in SW development for processors (like DSP, controller etc.), is used for debugging the implemented program, but the Mixed Language simulator has two addition features, the special display modes and the automatic error detection.

1.δ.1 Program display option

Fig. 6 is a screen shot illustration of the display modes windows of the simulator program 610, showing display options including Algebraic and Mixed, High-Level and Low-Level Language Windows, constructed in accordance with the principles of the present invention. Simulators of processors, such as DSP, etc., usually having two display options of the tested program: the low-level language option, known as the disassembly window and the high-level language option that is usually the C window. The Mixed Language Simulator may have a number of display modes of the tested program:

the Mixed Language program display mode, is shown in Fig. 6 as the 'Mix Language Window' 620, and displays the source expressions of the ML program;

the high-level program display mode, is shown in Fig. 6 as the 'High-Level Language Window' 630, presents HL program expressions, that were extracted from the ML program by the compiler;

the algebraic code display mode, is shown in Fig. 6 as the 'Algebraic Window'

640, presents Algebraic representation of the ML program extracted by the compiler;

the low-level program display mode, is shown in Fig. 6 as the 'Low-Level Language Window' 660, presents the LL expressions of the program. The displayed data contain the address in the processor memory, the machine opcode and the LL (disassembly) command; and

any combination of the above display modes.

Fig. 7 is a screen shot illustration of a simulator program 710 showing a 'Mix Window', that presents two, three or four of the display modes of Fig. 6 in one window, constructed in accordance with the principles of the present invention. Fig. 7 shows the 'Mix Window' 720, which presents two, three or four display modes in one window. Each line has prefix that defines the display mode of the line: ML - ML expression 730, HL - HL expression 740, AL - Algebraic expression 7δ0 and AS - for the LL (assembler) 760 commands. Each mode may be used for the debugging process, the high-level program display mode displays the high-level language and thus it is the most convenient way to debug the program. If needed more details of the low-level code and keeping the high-level code than the Mixed Language display mode is preferred. And in other cases the low-level display mode and the algebraic code display mode may be used. The ML simulator receives the program in it's various display modes from the ML compiler via the compilers list file output and display them according to the user request.

The debugging process of the simulator may be performed step by step on each line of the above display modes.

1.δ.2 Simulator Error Detection

The automatic error detection in the ML program is based on the structure of the ML syntax that includes two programming languages representing the same algorithm in one ML program. The two programs are combined and linked to each other almost on every line, thus one of the resulting properties of the combined language program is that the flow and results of the programs may be compared on every step of the program, and if detected any dissimilarity or miss identity in any step of the program then error message may be produced, including error location and error details.

There are several error types that the simulator may detect, each of the error types may be enabled or disabled according to operation mode selection, or a specific error check may be enabled or disabled in a specific range of code lines. For example, it may be specified that the whole program be checked for all error types, except that for a specific range of code lines the 'variables to registers association' test will not be performed.

The error test types are:

differences in the program flow, for example differences in perform conditional branch commands;

variables and registers association;

address check on memory access - When the high and low level programs access memory, then according to the high-level variable accessed perform a check that the low-level language program access the correct address; value compare on read/write to memory - When the high and low level programs access memory on read or write, then compare the values read/write by the high-level program to the low-level program;

expression result comparison - compare the evaluation result of the high-level program to the low-level program;

variable reference test - detect unused variables; and

fast detection - reduces test time.

1.6.2.1 Differences in the program flow

Differences in the program flow errors may be detected by the simulator.

This is done by processing the high-level and the low-level language programs, and testing that the programs perform the same associated commands. That is since the high-level and the low-level programs are extracted from the same Mixed Language program, and thus the high-level expression and the low-level command that was extracted from the same ML expression are associated one to the other.

This way the ML simulator may detect bugs in execution of conditional branch, or detect if loops are performed at different times in the high-level language program vs. the low-level language program, etc.

Example:

|<ar1 = &vect[0]>|;

|<ar4 = &coeff[0]>|;

|<rpt (size)>| |{for(I=0;Ksize+1;l++)}| // 'rpt' is the TI assembler command // for loop over the next command //line 'size+1' times

{

sum = sum+|<*ar1+{=vect[l]}>| * |<*ar4+{=coeff[l]}>|; }

The ML simulator performs the summation in the high-level program and in the low-level program. If detected that the LL and HL programs are executing different expression, for example the HL program continue the loop and the LL program exits the loop (due to different values of 'size' in the high-level vs. the low-level programs) then error message may be produced.

1.6.2.2 Variables and Register association

The ML simulator may detect registers to variable association errors - similar to the ML compiler association test with' the difference that the simulator may check association with items in arrays. This error detection is based on the ML syntax that is associates and represents the high-level program variable with the processor HW modules' registers. For example, if the simulator detects that the program assumes that a register represents a certain variable, but the last association of this register was to represent another variable, then an error message may be produced. The expression below demonstrates this feature:

|{var1}||<a>| = 1; (ml)

|<{var3}=a>| = |<a{var1}>| * 2;^" (m2)

In this example register 'a', which represents variable 'vart' according to (ml), is loaded in (m2) by '1' and then is multiplied by two and moved to var3.

If the Mixed Language program is:

|{var1}||<a>| = 1;

|<{var3}=a>| = ]<b{var1}>| * 2;

The simulator, while executing the program, may detect that in the first line register 'a' is assign to represent vart , but in the second line the syntax '|<b{vart}>|' interpretation is that register 'a' represent 'vart', which contradicts the first line and error message may be produced.

The method for error detection may be performed by filling-in an Association

Table (described below) that specifies the representation and connection between the high-level program variables and the low-level registers. This table includes information specifying the register name, to what variable it is associated and the type of the association - i.e., whether it is a variable or a pointer.

If a copy between two registers is perform then according to the copy operation the association of the destination register is updated. For example the case of copy 'regl = reg2', in which case the association of 'reg2' is copied to the association of 'regl', or if 'reg1=*pntr_reg' and 'pntr_reg' is associated to 'vart' with association type of pointer, then regl association in the association table is filled with the variable 'vart' and the association type is value.

In the other direction, on any operation that assumes that a register is associated with a certain variable, the association and the association type are checked in the Association Table, and if a contradiction is found, then an error message is produced.

For example, on program execution the simulator reads the following expression:

|< {var1}=b>l = 100; (ml) |<ar1 = &array[0]>|; (m2)

then, after execution of the first expression (ml), the Association Table is filled- in by the simulator and associate register 'b' is 'vart' with association type 'value', and the interpretation of (m2) is that register 'art' and array[] buffer are associated with association type 'pointer':

And when the expression:

b{=var1}>| *2 + |<*ar1{=array[0]}>| (m3)

is processed by the simulator as follows: checks that register 'b' is associated with the variable 'vart'; multiplies the content of register 'b' is by two; checks that art is associate with array[] and 'association type' is pointer; and performs the 'Add' operation: b + *ar1.

An example for expression error is the following:

b{=var2}>|*2 +

(m3 error)

On this expression is it expected that register 'b' represent 'var2'. The simulator analyze the expression and then check in the Association Table if register 'b' represents 'var2' - which is not true (since register 'b' represents 'vart'), thus an error message may be produced.

On the second part of (m3), art is expected to represent buf[] - which contradict the association table, thus another error message may be produced. Example 2:

Consider the following High-level sequence:

var3 = var4«2; (hi)

varδ = array[0]+100; (h2)

vart = var3+array[1]+3; (h3)

The Mix Language:

|<{var3}a>|= var4«2; (ml)

|<ar1 = &array[0]>|; (m2)

|<{varδ}= b>| = |<b=*art+{= array[0]}>| + 100; (m3)

|<{var1}=a>| = |<b{=var3}>| + |<*art{=array[1]}>j + 3; (m4)

Simulator error detection process:

After execution of (ml) the Association Table is updated with the information that register 'a' represents 'var3':

Note that the new information is in New (italic bold underline).

(m2) is updated, such that art points to array[0]:

art pointer &array[0]

In' the expression (m3): the first expression to be examined is "|<b=*ar1+{= array[0]}>|', where within this expression the simulator starts with '*ar1+{= array[0]}', which causes the simulator to check that art represents '&array[0]' and that the association type is pointer, i.e. register art points to the &array[0] buffer.

Next, the expression: 'b = *ar1 +' is performed with a post increment of art .

Thus the contents of '*ar1' is copied to register 'b,' and the Association Table is filled-in with the information that register 'b' represents 'array[0]\

And then the increment of art is performed, and the table is updated:

After the register 'b' value is incremented by 100, the simulator copies the contents of register 'b' to 'varδ' and updates the Association Table:

The (m4) ML expression: |<{Var1}=a>| = |<b{=var3}>| + |<*art{=array[1]}>| + 3

The first expression to be handled is '|<b{=var3}>|' implies that register 'b' is expected to represents 'var3', but according the Association Table register 'b' represents 'varδ', thus there is an error in the ML (m4) expression and error message may be reported, including error location and error details.

If (m4) is corrected:

|<{Var1}=a>l = |<a{=var3}>| + |<*ar1{=array[1]}>| + 3; (corrected m4)

Then the expression '|<a{=var3}>|' implies that register 'a' is expected to represents Var3' .which is true according to the Association Table. Next the expression '|<*ar1{=array[1j}>|' implies that art points to '&array[1]', which agree with the Association Table. After the addition of 'a = a+*ar1' and 'a = a+3' then the result is stored in 'vart' and the Association Table has to be updated with association between register 'a' and 'Vart':

1.δ.2.3 Address check on memory access

When the high and low level programs access variables in memory, then the ML simulator may check that the low-level program access the correct address in the memory. This check is performed by the simulator by a number of steps:

i. analyze the variable that the high-level program is accessing

ii. find the address of that variable in the low-level program, for example according to the linker output map file.

iii. Find the actual address that the processor is about to access. This address is found out by the simulator while execute of the program.

iv. Compare the address found in step b - the expected address, to the address found in step c - the actual access memory address. If the addresses are not equal then an error message may be produced.

Example:

Consider the following high-level expression:

Varδ = array[1];

Vart = array[0];

The ML program:

|asm:ld #1 , DP>|; (ml)

|<art = &array[1]>|; (m2)

|<{Var1}=a>|= |<*ar1+{=array[1]}>|; (m3)

|<{Var2}=a>| = |<*ar1{=array[0]}>|; (m4) Assumptions regarding the linker output data:

&array[0] is located in address 1000h

Vart is located in address 80h

Var2 is located in address 201 h

The ML simulator execution steps:

after (m ) and (m2) the DP equals 1, and art equals 1001h (= '&array[0]+1');

the execution of (m3) starts with the expression '|<*ar1+{=array[1]}>|', and the simulator checks that register 'art' pointes to array[1]:

the high-level program accesses the array[1];

thus, the simulator may find that the array[1] address in the low-level program is located at address 1001 h;

the actual address that the processor is about to access is 1001h, which is the constant of art ; and

thus, the two addresses of the previous two steps are equal to

1001 h and this test result is OK;

the next expression is '|<{Var1}=a>| = *ar1+'. The contents of address 1001h is then passed to register 'a' and it is about to be stored in 'Vart':

the high-level program access the Vart ;

thus the simulator may find that the Vart address in the low-level program is located at address 80h;

the actual address that the processor is about to access is 80h. That is since the address is calculated using DP, Vart is allocated at address 80h, and it is accessed in direct addressing. Thus, the low- level program address is 80h; and thus, the two addresses of the previous two steps are equal to 80h and this test result is OK;

the execution of (m4) starts with the expression '|<*ar1{=array[0]}>|' ;

the high-level program access the array[0];

thus the simulator may find that array[0] address in the low-level program is located at address 1000h;

the actual address that the processor is about to access is 1002h. That is since the content of art is 1002h. (art was initialize to 1001h and was incremented in (m3)); and

thus the two addresses of step b and c are NOT equal and therefore an error message may be reported, and

the next expression is '|<{Var2}=a>| = *ar1'. The contents of *ar1 is then passed to register 'a' and it is about to stored in Var2':

the high-level program access the Var2;

thus the simulator may find that Var2 address in the low-level program is located at address 201 h;

the actual address that the processor is about to access is 81 h. That is since the address is calculated using DP, because Var2 is accessed in direct addressing mode. Since DP=1 and Var2 is located at address 201 h, therefore the address that the simulator will access is 81 h; and

thus the two addresses of the previous two steps are NOT equal and therefore an error message may be reported.

1.δ.2.4 Value compare on read/write to memory When the high and low level programs access memory on a read or write operation, then the ML simulator may compare the values of the low-level and the high-level programs. The compared values depend on the ML expression syntax described in the table below:

(*1) LL(var) denotes the value of the variable according the low-level program in the memory,

(*2) HL(var) denotes the value of the variable according the high-level program.

'reg' and 'regl' - may be LL language register expression like register 'a', 'ar3',

'*arδ' etc.

The first three cases (1 , 2 and 3) relate to the expression on the right side of the equation. While cases 4,6 and 6 relate to the left side of the equation (the destination of the result). Case number seven may be used when no comparison between LL and HL program is to be performed.

In the first case, 'var' is defined in the LL program memory, the LL program copy the value of 'var' to register 'reg'. The comparison is between the value of 'var' in the HL program to the LL program memory. Since the 'var' in the LL program is not change in this expression, then the comparison may be performed before or after the copy execution.

In case 2, 'Var' is allocated in the LL program, and is expected to be represented by register 'reg', thus the comparison is between the register 'reg' and 'var' of the HL program. Since the register 'reg' is^' not changed in this expression, then the timing of the comparison is not important.

In the case 3, 'var' is not allocated in the LL program, and it is expected to be represented by register 'reg', thus the comparison is between register 'reg' and 'var' of the HL program. Since register 'reg' is not changed in this expression, then timing of the comparison is not important. In Case 4, which relates to the left side of the equation, the expression result is moved to 'reg' and then to 'var'. The comparison is between the 'var' of the LL program to the 'var' of the HL program. Since the comparison is between the LL program 'var' then the comparison timing has to be after the value was copied from 'reg' to 'var'.

In Case 5, which relates also to the left side of the equation, the expression result is not moved to 'var', thus the comparison is between register 'reg' and the 'var' of the HL program. The comparison has to be performed after the expression result was copied to 'reg'.

In Case 6, which relates also to the left side of the equation, after 'reg' receives the expression result, then the result is also moved to 'regl'. The expression result is not moved to 'var', thus the comparison is between register 'regl' and the 'var' of the

HL program. The comparison has to be performed after the expression result was copied to 'regl '.

Case 7 represents the above cases, and may be used when no comparison between the HL and the LL programs is to be performed.

Example:

|<ar1 = &array[0]>|; ^" (ml)

|<{Var5}= b>| = |<b=*ar1+{= array[0]}>|+100; (m2)

|<{Var1 }a>| = |<b{?=var3}>| + |<*ar1 ={array[1 ]}>| + 3; (m3)

Expression (ml) is assignment of the LL program, thus it dose not cause any comparison.

Expression (m2):

First the expression '*ar1+{= array[0]}' is analyzed, the high-level program array[0] value is compared with the low-level program memory of address *art (case 2 in the table). Then, the expression '|<{Varδ}= b>|' which describes the store operation of (m2), causes the simulator (after the store result into varδ) to compare the high-level program value of Varδ to the low-level program memory value of Varδ (case 4 in the table).

Expression (m3):

The expression '|<b{?=var3}>|' causes no comparison - (case 7 in the table).

The expression '|<*art={array[1]}>|' cause the simulator to compare the value of the high-level program variable array[1] to the low-level value of array[1] in the memory (case 1 in the table).

The store operation of (m3) - expression '|<{Var1}a>| = ' causes the comparison of register 'a' with the HL program variable Vart' (case δ in the table).

1.δ.2.δ Expression Evaluation

On expression evaluation, which include the '=' sign between the left and the right sided of the expression, then a comparison is performed between the results of the high-level program to the low-level program.

Example:

var1 = 1 ;

|<{var3} = a>| = |<a = {var1}>| «2;

The high-level program operand for the comparison is: vart = 1

var3 = vart « 2 // var3 = 1 « 2 = 4

And the result of the HL program is Var3 = 4' And the low-level program operand for the comparison is:

vart = 1

(var3=a) = (a=var1) « 2 // (var3 = a) = 1«2 = 4

And the LL program result is Var3 = 4'

Since the two programs result is the same, thus the comparison result is

OK.

1.δ.2.6 Variable Reference Test

The variable reference test is a test that checks if a variable, which is included in the HL program, is used by the LL program in order to eliminate the declaration and allocation of unused variables in the LL program. This test is important since the ML program includes the HL and the LL expressions and there may be variables that included in the HL program but the LL program dose not need (like temporary variables etc.) because of the optimization.

Fig. δ is a flow chart of a variable reference test 600 to check for errors in the LL program variables declaration, constructed in accordance with the principles of the present invention. The implementation of this test may be performed by a state table, shown in Fig. δ, which includes all HL program variables. In this state table all variables are initialized to the state 'variable uninitialized' 610, and then the status is changed according to the variable operation. For each variable there is a status word, which is modified according to the program operation, read or write 620.

For example, if the program has variable name 'var' then before the program starts this variable will be initialized to state 'variable uninitialized'. Then if a write operation is performed on this variable, according to the state table in Fig. δ, the status of the variable 'var' will be changed to Variable written' 630.

The variable status options in the state table are: - variable uninitialized 610 - no write or read was performed to this variable

- variable written 630 - only a write operation was performed to this variable

- variable write and read 640 - write and then read operation to this variable was performed

- variable read 660 - only read operation was performed

- variable read then write 660 - the write operation from this variable was performed after read operation

- variable read then write read 670- after the read operation, a write and read operation were performed.

Test operation:

While the LL program is executed the table is filled and after the program terminates the status of each variable defines it's state ERROR or NO ERROR according to the following states:

1- variable un initialized - no write or read was performed to this variable - ERROR 1 : this variable is not used by the LL program.

2- variable written - only write operation to this variable was performed - ERROR 2: Only write operation was performed to this variable, no read operation was performed by the LL program.

3- variable write and read - write and then read operation to this variable was performed - NO ERROR this variable was written to and then read from.

4- variable read - only read operation was performed - ERROR 3: the program only read from this variable - variable is not initializing by the LL program. δ- variable read then write - the write operation from this variable was performed after read operation- ERROR 4: unexpected read/write access to this variable by the LL program.

6- variable read then write read - after the read operation, a write and rear operation were performed. - ERROR δ: The program seems to access this variable without initialization For example if the program has variable name 'var' then this variable will be initialized before program starts to state 'variable un initialized'. Then if write operation if perform to this variable then, according to the state table in Fig. δ, the status of the variable 'var' will be changed to 'variable written'. If after this operation the program terminates then the final status of 'var' is Variable written' which specify Error 2.

Variable test per variable type - global or temporary:

Variables are initialized on their definition - e.g. Global variables status is initialized on power up and they 'exist' until program terminates. Local variable lifetime is limited from start of routine where they are initialized until return to calling program or program termination, thus they are initialized on each entry to the routine and they are checked after they return to the calling program or program termination.

1.6.2.7 Fast Detection - reduces test time

In order to shorten the execution time of the test, the test may be performed in the following way:

- Set a break point at a location before the suspected error. - Free run of the HL and LL tested programs until the break point.

In this test phase the tests described in the Simulator Errors Tests are not performed thus reduce the number of calculations used by the simulator, and reduce test time.

- The simulator is halted on the break point location, which is before the location of the SW error.

- Then the simulator enters the Test Mode in which the program is executed step by step: o The HL and LL programs are executed step by step. o Each expression is analyzed and the history test data bank, like the Association Table, are updated. o If an expression does not need any history test data or the history test data exists then this expression is tested by the selected error test. o If an expression does need history test data that is not included in the history test data then the test is not performed on this expression.

1.6 Mixed Language Emulator Development Tool

The Mixed Language emulator enables testing of the implemented program on the 'real-time' target processor environment. The Mixed Language Emulator, similarly to general emulators used in SW development for processors (like DSP, controller etc.), is used for debugging the implemented program on the 'realtime', but the Mixed Language emulator has two addition features, the special display modes and the automatic error detection.

1.6.1 Program Display Modes

Emulators of processors (like DSP etc.) usually having two display options of the tested program: the low-level language option, known as the disassembly window and the high-level language option that is usually is the C window. The Mixed Language Emulator, similarly to the ML Simulator, may have a number of display modes that are described in the Simulator Program Display Modes in section 1.5.1.

1.6.2 Emulator Automatic Error Detection

Error detection as described in the simulator section (sec 1.5) may not be performed during free run time of the emulator. That is, since total control of the program is in the processor, but automatic error detection may be performed after the emulator halts and executes the program step by step and performs the tests as described in the simulator error detection section.

Since the error detection is based on comparison of the HL program execution and the LL program execution, and when the emulator stops anywhere in the LL program and the HL program is not updated, then the LL program may update the HL program variables, and after the variables where updated then the automatic error detection process as describe in the simulator section may be performed while the emulator executes the program step by step.

The place in the LL program that the emulator is stopped is very important, since the LL program is about to update the HL program, thus in order to ensure proper operation of the error detection process, it is important to stop the emulator (by break point) at a location that the program executes without errors.

The emulator error detection operation steps:

1) A break point is set in the tested program. 2) Free run of the LL program.

3) The LL program stops at the break point

4) The Emulator is set to the 'automatic error detection mode' and starts errors detection process which includes:

I. The emulator reads an expression and tests all variables if their value in the HL program is valid. This is done by the 'HL Validation' table, which contains all HL program valid variables - the variable name and the value.

II. If the expression contains any HL variable that is not included in the 'HL Validation' table, which means that because of that the HL program was stopped in the middle then this variable value is unknown. In this case the variable value in the HL program is updated by the variable value of the LL program, and the 'HL Validation' table is updated with the updated variable name and value. III. The tested expression is analyzed according to the requested test and the history test data, like the Association Table, are updated.

IV. The requested test for the expression will be perform if all it's HL program variables are valid and all history test data needed information is valid (like the information in the

Association table). The error detection is performed as described in section 1.5.2 'Simulator Error Detection'. V. Steps (i) to (iv) are continued, and on some stage all history data will be updated, then the test will be perform as described in section 1.6.2 'Simulator Error Detection'.

Example:

Consider the following expressions which calculate an index and then summation is performed on the buf[] items from item index until item index+4: Note, the example is focused on the error detection process and not on other operations like execution of the program.

HL program:

index = index_calc(); // calculate the index

Sum = 0; // clear 'Sum'

For (I=0;Kδ;l++)

{ sum = sum + buf[l+index]; // summation of buf[index:index+4] }

ML program:

|<index{b}>| = index_calc(); // calculate the index

|<Sum{a}>| = 0; // clear reg 'a' = 'Sum' |<(ar1 =b ) = b+#buf>|; // calculate address of buf[0+index]

|<brc = #4>|; |{For (l=0;K5;l++)}||<rptb>|

{

|<{sum}a>| = |<a{sum}>|+ l<*art+{=buf[l+index]}>[;// summation of

//buf[index:index+4]

} Assumption 1 :

Buff] is a constant buffer.

The HL program buf[]:

Buf[] = 1 ,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16

In the LL program, the buffer 'bufjf ' is located in address 0x1000

For the error detection demonstration an error is included in the LL buf[2]:

Buf[] = address 0x1000: 1,2,0,4,5,6,7,8,9,10,11 ,12,13,14,15,16

Assumption 2:

The error detection mode that is activated is option 5 of the 'simulator error detection'/ 'Value compare on read/write to memory' presented in section

1.5.2.4: 'When the high and low level programs access memory on read or writes, then compare the values read/write by the high-level program to the low- level program.'

The debugging process:

1) The debugging process starts by setting a break point in a place which has no error and located before the area of bug. Therefore assumption is taken that it is known that the bug is somewhere in the loop operation.

2) A break point is set on the 'for' statement:

|<index{b}>| = index_calc(); // calculate the index

|<Sum{a}>| = 0; // clear reg 'a' = 'Sum'

|<(art=b ) = b+#buf>|; // calculate address of buf[0+index]

|<brc = #4>|; BP» |{For (l=0;K5;l++)}||<rptb>| {

|<{sum}a>| = l<a{sum}>|+ |<*ar1+{=buf[l+index]}>|;

//summation of .

//buf [index: index+4]

}

|<sum = a>|;

3) The LL program is executed on the target processor.

4) The LL program stops at the break point

Assumption: when the program stops the registers are:

δ) The Emulator. is set to the 'automatic error detection mode' and starts errors detection process according to the described above in the assumptions .

6) A 'HL variable table' is initiated: HL variables table:

This table will be update with every HL variable that the emulator finds.

7) Expression '|{For (l=0;l<5;l++)}||<rptb>|' is executed -

The LL program initiates the 'rptb' loop operation

The HL program update the 'HL variables table' with the value of

HL variables table:

8) Expression '|<{sum}a>| = |<a{sum}>| + |<^*art+{=buf[I+index]}>|;'

Value read/write error detection:

The first expression handled is: |<a{sum}>|

According to the table in section 1.6.2.4: 'Value compare on read/write to memory' the comparison 'case no.' is number 3 and the comparison is performed between 'reg == HL(var)' , or in this case the 'reg is register 'a' and the HL(var) is 'sum'.

It is expected that that value of register 'a' will be equal to 'sum' of the HL program.

Since the value of 'sum' is unknown, i.e. since the ML program, which also describes the HL program, was stopped in the middle.

But since break point assumption is that until that location there was no error in the program, then the value of register 'a', which is expected to be equal to 'sum', is correct therefore the above table may be update:

HL variables table:

The next expression handled is: |<*art{=buf[l+index]}>| this expression includes memory access; and the LL program access memory at address pointer by *ar1 ; the HL program access 'buf[I+index]'; ι the variables in this expression, includes: T, 'index' and 'buf; the value of T is known in the 'HL variables table'; and the value of 'buf is known since it is the table address; the value of 'index' is unknown therefore the 'l+index', of the HL program, can not be calculated using the value of 'index'; and according to the ML file 'art' points to address in the range of buf[], thus the index in the 'buff]' buffer is : ar1=I+index+&buf[0]. Where 'art =0x1001', T = 0, '&buf[0]=0x1000' then 'index' may be calculated by: index = art- 1- &buf[0] = 0x1001 - 0 - 0x1000, And index = 1 which may be update in the 'HL variables table'.

HL variables table:

The next step is evaluation of

10 '|<{sum}a>| =|<a{sum}>| + |<*ar1+{=buf[l+index]}>|' The HL program updates the 'HL variables table' with the result Sum = 2

HL variables table:

15 The emulator executes the expression and test that after the execution: reg 'a' = Sum = 2 the HL and the LL result are equal.

9) Expression '|{For (l=0;I<δ;l++)}|I<rptb>|' is executed -

20 - The 'rptb' next cycle is updates and the HL variables are update according to the ']{For (l=0;K5;l++)}|'

HL variables table:

10) Expression '|<{sum}a>| = |<a{sum}>| + |<*ar1+{=buf[l+index]}>|;'

The first expression handled is: |<a{sum}>| which is true The next expression handled is: |<*ar1+{=buf[l+index]}>|

All the HL variables , I and index, in this expression are known The LL '*ar1 ' points to address

1002 contains: 0

The HL 'buf[l+index] expression is examined: According the 'HL variables table' 1=1 and index = 1, therefore buf[l+index] = buf[2] = 3.

Thus the LL reads the value: 0 while the HL access buf[2]=3.

And ERROR message may be produced.

1.7 Applied steps for the Mixed Language

The Mixed Language method implementation is composed of a number of steps, which contents are depends on the high-level language used and on the low- level language used. Each LL language has its commands, registers and specific rules, such as latency rules, etc. Information contained herein is based on the Tl's DSP tms320cδ4. Accordingly the Mixed Language may be written for other processing units with adjustments for the specific processing unit in use. The implementation steps required for other processing units are:

1) Definition of the Mixed Language rules for the pass form high- level language and the low-level language. Rules examples are presented in section 1.8

2) Compiler implementation is performed according to the above rules and it's properties are described in section 1.4.

3) Simulator implementation is performed according to the above rules and it's properties are described in section 1.6.

4) Emulator implementation is performed according to the above rules and it's properties are described in section 1.6. 1.8 Mixed Language Rules

The following is an example for rules for the Mixed Language code. The rules are written for the high-level C language and the low-level language is Tl's DSP tms320c54.

The rules are given as an example, more rules may be added and may be changed for other high-level language and/or low-level language.

1.8.1 High-level and low-level distinguish method

The method distinguishes between the high and low level languages in order to be able to extract the 'pure' high-level language and a 'pure' low-level language from the Mixed Language program. The distinguish is performed according the following rules:

each part of the code between '|<' and '>|' is a part of the low-level language;

each part of the code between '|{' and '}]' is a part of the high-level language;

other part of the code which are not between the above two options are common to the high and low level language; and

mixed expression: that includes high-level items inside the |< >|:

|<{hhhhh }lllll >|

where the 'hhhhh' represents high-level expression and the 'HIH' represents low- level expression. The expression 'hhhhh' appears between the |< >| (which is sign for low-level expression), but inside the |< >| the 'hhhhh' is surround by { } which is the sign for high level expression. This signs that the 'hhhhh' is high level only.

There are a couple of method for combine the low and the high level expression, below are few examples: a. C language code: y0_ptr = &y0_buf[0]; y0_ptr = y0_ptr + 1 ;

May appear in the Mixed language as:

|<art>||{y0_ptr}| = &y0_buf[0]; // LL: register art points to y0_buf

|<*art+>| |{y0_ptr = y0_ptr + 1}|; // distinguish of HL and LL in //separate expression, where the //HL expression is surrounded with //'|{ }|' and the LL expression is //surrounded with '|< >|'

Reconstruct High-Level is performed according to the above rules:

y0_ptr = &y0_buf[0];

y0_ptr = y0_ptr + 1 ;

Algebraic code (AL):

art = #y0_buf;

*art+;

The low-level code:

stm #y0_buf, art // art points to buffer y0_buf

mar *art+ // art = art+1

Thus the base for extraction of the high-level language program may be extracted by eliminate every thing that is outside the |{ }|. The low-level command may be extracted by eliminate every think that is outside the |< >|.

b. High-level source program: sum = 1;

sum = sum +CONST;

May appear in the Mixed Language as:

|<{sum}a>| = 1 ; // register 'a' is equivalent to sum.

|<{sum}=a>| = |<a{sum}>| + CONST;

Compiler high-level language program out:

sum = 1;

sum = sum + CONST;

Algebraic code (AL): a=1 ;

a = a + CONST;

sum = a;

low-level language: Id #1 , a

add #CONST, a

stl a, sum

1.8.2 ML Basic Expressions: Connection and Operation Between High-Level and Low-Level

This section defines the relationship options between the low-level language registers and variables to high-level language variables.

The relationship is divided for two cases: 1) Expressions on the right side of the equation, which their execution results the source of the equation.

2) Expression on the left side of the equation, which define what to do with the result of the right side of the equation.

for example the equation:

Var2 = Vart + CONST;

is an example for a simple equation where the right side is consist of 'Vart + CONST'. The left side of the equation consist of 'Var2' defines that the result of 'Varl + CONST' is stored in Var2.

Each ML expression defines:

LL Operation and relationship between the HL variable and the LL registers;.

HL output argument - is used in the HL reconstructed program. It defines the argument of the HL expression in the reconstructed HL program; and

LL output argument - is used to construct the LL program. It defines the argument of the LL expression in the LL program.

Each expression define in this section is used for the automatic error detection mechanism described in the development tools section.

1.8.2.1 Expressions on the right side of the equation

Expressions on the right side of the equation are the expressions which defines the calculation of the equation, and the calculation result are stored in the variable defined on the left side of the equation.

There are several options for the relationship connection between the high- level language variables, the low-level language registers and variables. The below symbols refer to: Var' - high level and or low-level language variable, and 'reg' - register of the processor that can be addressed by the low-level language.

i) Load the low-level register with the variable value:

|<reg={var}>|

This expression is used when an expression needs to load a LL variable to a register inside an expression.

For an example the expression '|<b={var}>|+1' which indicates that 'var+1' operation has to be perform. This is done by specify in the ML program that 'var' value is loaded to register 'b'.

The expression defines:

LL Operation: value of 'var' is loaded from memory and stored, in register 'reg'.

LL Expression output: 'reg'.

HL Expression output: 'var'.

Automatic error detection: refer to 'Error Detection' description in the Compiler, Simulator and Emulator sections.

Example:

|{var1}H| = |<b={var}>|+1; .

First the ']<b={var}>|' expression is analyzed:

LL Operation: value of 'var' is loaded from memory and stored in register 'b.

LL Expression output: 'b'.

HL Expression output: 'var'. After the ML expression '|<b={var}>|' analyzed then the whole expression may be translated using the above analysis:

High-level: vart = var+1; //The 'HL Expression output' is used:

//Var1=HL Expression output'+1'

Algebraic code (AL): b=var; // note that the LL Expression output,

b= b+1 ;//register 'b', is used:

// b = 'LL Expression output' +1

Low-level: Id vart, b

add #1 ,b

ii) The expression:

|<reg{=var}>|

expects that the register 'reg' to be equal to the high-level language variable 'var'. In addition if 'var' is declared in the low-level language then 'reg' is expected to be equal also to the LL variable Var'. This syntax is used when the HL variable 'var' is also declared in the LL program. No action has to be performed in the low-level language program.

This syntax is used when the register value already contains the value of the variable 'var'. The aim is for software flow clarification- define that register 'reg' represents the variable 'var', and for the SW development tools automatic error detection (Refer also to the section described the development tools).

The expression defines: LL Operation: No operation of the LL program.

LL Expression output: 'reg'.

HL Expression output: 'var'.

Automatic error detection: refer to 'Error Detection' description in the Compiler, Simulator and

Emulator sections.

Example:

|{vart}||| = |<b{=var}>|+1 ;

First the '|<b{=var}>|' expression is analyzed:

LL Operation: No operation.

LL Expression output: 'b'.

HL Expression output: 'var'.

After the ML expression '|<b{=var}>|' analyzed then the whole expression may be translated using the above analysis:

High-level: vart = var+1;

//The ΗL

Expression . output' is used://Vart=HL Expression output'+1'

Algebraic code (AL): b = b+1; // note that the LL

Expression output,

//register 'b', is used:

// b = 'LL Expression output'+1 Low-level: add 1 ,b

iii) Variable 'var' is equivalent to the register 'reg'

|<reg{var}>|

This syntax is used when register 'reg' represents the variable

'var' and it is expected that the value of 'reg' equals to the value of the HL program variable 'var'. The LL program performs no action.

This is used when 'var' was not allocated by the low-level due to temporary variable optimization and in the program flow the register 'reg' represents the variable 'var'. The expression defines:

LL Operation: No operation of the LL program.

LL Expression output: 'reg'.

HL Expression output: 'var'.

Emulator sections.

Example 1 :

|{vart}||| = |<b{var}>|+1 ;

First the '|<b{var}>|' expression is analyzed:

LL Operation: No operation.

LL Expression output: 'b'.

HL Expression output: 'var'.

After the ML expression '|<b{var}>|' analyzed then the whole expression may be translated using the above analysis: High-level: vart = var+1; //The 'HL Expression output' is used:

//Var1=HL Expression output'+1'

Algebraic code (AL): b = b+1; // note that the LL

Expression output,

//register 'b', is used:

// b = 'LL Expression output'+1

Low-level: add 1,b

iv) Two registers expression:

The two registers expression may be added to expressions that contains no move operation between the variable to the register, like the:

|<reg{=var}>|

or

|<reg{var}>|

and if needed that the expression output will be other registers then the 'reg'. Then the following syntax may be applied in order to change the expression output register:

|<reg1=reg{=var}_'

or |< reg1=reg{var}>|

Where 'reg' may be a register or pointer to memory, refer to the examples below.

The expression defines:

LL Operation: regl = reg , the value of 'reg' is loaded to regl

LL Expression output: 'regl'.

HL Expression output:

Example:

High-level: vart = var2+var3;

ML program |<{var1} =a>| = |<a=*ar1{=var2}>|+var3;

First the expression '|<a=*ar1{=var2}>|' is analyzed:

LL Operation: *art.

LL Expression output: 'a'.

HL Expression output: Var2'.

After the ML expression '|<a=*ar1{=var2}>|' analyzed then the whole expression may be translated using the above analysis:

High-level: vart = var2+var3; //The 'HL Expression output' is

//used: 'vart ='HL Expression output'+var3 Algebraic code (AL): a=*ar1 ; // note that the LL Expression

a=a+var3; //output, register 'a', is used:

var1=a; // a = 'LL Expression output'+var3

Low-Level:

Ld *ar1 , a

Add var3, a

Stl a, vart

This syntax is useful for example when the parameter var2 value is already pointed by art (or the value is already in other register like register 'b'), and since the low-level program may accumulate only on accumulators then it is needed to move the value form *ar1 to any accumulator, in this case register 'a', and then proceed the expression execution.

1.8.2.2 Expressions on the left side of the equation

Expressions on the left side of the equation are the expressions that define what to do with expression result.

After the right part of the equation (right to the '=' sign) was calculated the result is to be stored according to the term on the left side of the equation (left to the '=' sign). This section describes the options of store the equation result.

The general format is of these expressions may be:

|<var=reg>| = expression // the expression result is stored in

//register 'reg' and then to variable Var'.

Example:

|<ar1=&array[0]>| // art points to first item in array[] buffer , __„, 036421

68

The left sides of the equation syntax options are: i) The Mixed Language expression on the left side of the equation:

|<{var}=reg>| = expression;

describes the operation performed on the calculated expression result. The translation to LL has three options:

K. If the expression calculation is perform on the specified register 'reg', for example accumulation operation on register 'a', then the mathematical operation is performed on register 'reg' and the result is copied to variable 'var'. n. If the expression calculation is not performed on the specified register 'reg' then the last calculation operation of the result is stored in register 'reg', and then move the result value to variable 'var'. λ. if (i) and (ii) can not be perform then the expression is performed on the register specified in, and after the calculation is done then the result is copied to register 'reg' and then to 'var'

The expression defines:

LL Operation: As described above

LL Expression output: 'reg', 'var'

HL Expression output: 'var'.

Example 1 - for case (i): |<{var1}=b>| = |<b{var2}>|+var3+1 ; The right side of the equation is analyzed, the accumulation is performed on register 'b' and the register specified in the left side of the equation is also register 'b', then the mathematical operation is performed on register 'b' and then the result is copied to 'var'.

The expression outputs are:

LL Expression output: 'b'.

HL Expression output: 'vart'. The final translation is:

High-level: vart = var2+var3+1 ; //The 'HL Expression output'

//is 'vart ' algebraic code (AL): b = b+var3; // the left expression result is in b=b+1; //register 'b' vart =b;

Low-level: add var3, b add #1,b Stl b, vart

Example 2 - for case (ii):

|<{var1}=a>| = |<b{var2}>|+var3+1;

The right side of the equation is analyzed, the accumulation is performed on register 'b', but in the left side of the equation register 'a' is specified. Since there is an 'add' operation which suits this combination:

'add #const, b, a

Then the translation to LL expression is as the following: The expression outputs are:

LL Expression output: 'a'.

HL Expression output: Vart'. The translation to LL is:

High-level: varl = var2+var3+1; //The 'HL Expression output' is

algebraic code (AL): b = b+var3; // the left expression result is a=b+1; //in register 'a' var1=a;

Low-level: add var3, b add #1,b,a // last accumulation is

//perform to register 'a'

Stl a, vart

Example 2 - for case (iii):

|<{var1}=a>| = |<b{var2}>|+var3^Λ2;

The right side of the equation is analyzed, the accumulation is performed on register 'b', but in the left side of the equation register 'a' is specified. Since there is no square operation which may perform the operation: a = b + var^Λ2

And there is square command operation:

b = b + var^Λ2

Then the translation to LL expression is as the following:

The expression outputs are:

LL Expression output: 'a'.

HL Expression output: 'vart '.

The translation to LL is:

High-level: vart = var2+var3^Λ2; //The 'HL Expression //output' is 'vart '

algebraic code (AL): b = b+var3^Λ2; // the left expression result is

a=b; //in register 'a'

var1=a;

Low-level: squra var3, b // b = b + var3^Λ2

Ld b, a //perform to register 'a'

Stl a, vart

ii) Store the expression result in register 'reg', The variable 'var' is not loaded.

|<{var}reg>| = expression or

|{var}||<reg>| = expression

Register 'reg' is assigned to represent variable 'var'.

The operation of this syntax is similar to the operation of the syntax '|<{var}=reg>| = expression;' presented in the above section 1.8.2.2.a. With one difference, which is that, the final result is not copied to 'var'.

The expression defines:

LL Operation: Explained in section 1.8.2.2.a, with one difference which is that the final result is not copied to 'var'.

LL Expression output: 'reg',

HL Expression output: 'var'. 6421

72

This syntax is used when the result dose not has to be loaded to the variable, for example when 'var' exist in the HL program but in the

LL program it is not allocated in memory (save memory space) and register 'reg' is used to represents 'var'.

Example is presented below as the 'Final HL and LL connection'. In this example the result of Var4«1' is saved in register 'a' and not written to Var2'. In the next expression: 'varl = var2+var3+3' the value of var2 is read directly from register 'a'.

iii) Three left side operands:

|<{var}reg1=reg>| = expression;

This expression is similar to the expression described in section 'b', but after 'reg' is loaded with the expression result then 'reg' is copied to 'regl'.

The expression defines:

LL Operation: Explained in section 1.8.2.2.b, with one difference which is the value of 'reg' is copied to 'regl'.

LL Expression output: 'regl',

HL Expression output: Var'.

Automatic error detection: refer to 'Error Detection' description in the Compiler, Simulator and Emulator sections. Example:

In the below example the calculation is performed on register 'a', and it has to be stored according register 'art' that points to the destination memory variable.

The ML expression:

|<{*pnt1=}*art =a>| = |<a=*art{=*pnt1}>| * 2 + var2;

HL code:

^*pnt1 = *pnt1 * 2 + var2;

AL: a= *art « 1;

a = a + var2;

*art - a;

Ld ' "art , 1,a

Add var2, a

Stl a, *ar1

1.8.2.3 LL Expressions: that refer only to the LL program

There may be a need for expression that will be included only in the LL program. These expressions needed, for example, when there is a need to set processor registers, like status register, stack pointer initialization, when there is a need to initialize pointer register before performing the loop, like:

Sum=0;

For (l=0;l<100;l++)

Sum = sum+array[l]; The translation for the ML:

|<ar1= &array[0]>|; // III Prepare art before loop execution

|{ Sum=0}|;

|<rptz a, #99>||{For (l=0;K100;l++)}|

|<{Sum}a>| = |<a{Sum}>|+|<*ar1{=array[l]}>|;

There are several options for the LL expressions:

i) |<(var=reg) >| = |<expression>| ii) |<reg>| = |<expression>| iii) two argument expression: |<arg_dst = arg_src >| arg_dst may be register or variable, arg_src may be register or variable or constant, iv) Number of expressions:

|<expression, expression, expression, ...>| Where 'expression' may be: reg=expression

(Var=reg) = expression arg_dst = arg_src

The following described the above four LL expressions: i) |<(var=reg) >| = |<expression>|

The LL operation is similar to that explained in section 1.8.2.2.a - 'Expressions on the left side of the equation'. Except that this syntax dose not cause any command in the reconstructed HL program.

Example:

ML code: |<(vart=a) >| = |<b{=var2}+ >|;

High-level: vart = var2+1;

Algebraic code (AL): a = b+1 ;

Low-level: add #1,b, a

Stl a, vart

ii) |<reg>| = |<expression1>|

The LL operation is similar to the expression

'|{var}||<reg>| = expression¹ which is described and explained in section 1.8.2.2 b. This syntax dose not cause any command in the reconstructed HL program.

Example:

ML expression: |<a>| = |<(b=var2)+ 1>|;

High-level: No expression

Algebraic code (AL): b=var2;

a = b+1;

Low-level: Id var2, b

Add #1, b, a

iii) Two argument expression: |<arg_dst = arg_src >| arg_dst may be register or variable, arg_src may be register or variable or constant,

Example: ML expression: |<ar1 = &array[0]>|;

High-level: No expression Algebraic code (AL): art = &array[0];

Low-level: stm #array, art

iv) Number of expressions:

|<expression 1 , expression 2, expression 3, ...>| Where 'expression' may be: reg=expression

(Var=reg) = expression arg_dst = arg_src

Which translate to: High-level: No action since this is a LL expression

Algebraic code (AL): a = vart ; a = a+1 ; vart = a; Low-level: Id vart , a

Add #1 , a Stl a, vart

Example: Final HL and LL connection

High-level: var2 = var4«1+array[0];^'

vart = var2+var3+array[1];

Mixed Language:

|<ar1 = &array[0]>|;

|<{var2}a>| |<a={var4}>|«1+ |<*ar1+{=array[0]}>|; //register

//'a' is loaded with var4«1 and then //'^*art+' is added

|<{var1}=a>| = |<a{=var2}>| + var3 + |<*ar1+{=array[1]>|;

// add to register 'a', which contain //the value of Var2', the value of //Var3' and '*art', which points to //'array[1]

Reconstructed HL program:

var2 = var4«1 + array[0];

varl = var2 + var3 + array[1];

Algebraic code (AL):

art = &array[0];

a = var4 « 1 ; // result of the expression '|<a={var4}>|«1'

a = a + *ar1+; // a = var2 = var4«1 + array[0];

a = a + var3;

• a = a + *ar1+; // a = var2 + var3 + array[1]; vart = a; // vart = var2 + var3 + array[1];

Low-level:

Stm #array, art // art = &array[0]

Ld var4, 1 , a //'|<a={var4}>|«1'

Add *ar1+, a // a = var2 = var4«1 + arrayjO];

Add var3, a

Add *ar1+, a // a = var2 + var3 + array[1];

Stl a, vart // varl = var2 + var3 + array[1];

1.8.2.4.1 Separate LL and HL Language expressions

In some cases it may be needed to separate the LL from the HL expression, for example when a loop mechanism has to be implemented and no special processor loop command is to be used, or when performing complicated HL instruction that is hard to modified to the described ML expressions, or in any case where the ML syntax which contains mix HL and LL expression in the same expression or line (such as '|{vart}||| = |<b{var}>|+1') is not to be used. In this case the separation of the LL and the HL expression may be performed by surround the HL expression with |{ HL expression}! and surround the LL expression with |< ^' LL expression^ or with

|asm:LL_language_command>|described below: i. Surround the HL instruction with |{ HL expression }| with no LL expression included between.

Note that there may be more then one-HL expression lines. ii. Write the equivalent LL expression or expressions:

Write the LL expression with |< LL expression >| with no HL expression included between.

And/Or Write the LL expression with the prefix of '|asm: >|'

Note that there may be more then one LL expression lines.

iii. Comparison the result of (b) . and (c). This is a development tools command written in the ML program and is used by the error detection process described in the development tools section.

In order to mark the expression line as a comparison command the line is marked at the end by '|<!Mixed compare>|'.

This line is not included in the LL or in the HL language programs, and it is executed only if the HL and LL programs are executed.

High level:

Var = expression; Mixed Language:

|{ Var = expression }|; (ml) |<Var= >|; (m2)

|<LL(Var){=HL(Var)}>|; |<!Mixed compare>|

Algebraic code (AL):

Var= ;// Algebraic presentation of (m2)

LL code:

Var= ;// LL language presentation of (m2) Example 1:

The HL language operation is the invert:

Var1=1 /var3*0x7fff;

In the ML syntax:

|{Var1=1 /var3*0x7fff}|; // the high level command will be not //referenced by the low-level //extraction process

|<a = #1«16>|; // calculate 1/var3

|asm: rpt #14>|;

|asm: subc var3,a>|; // result in register a

|<a{=var1}>|; |<!Mixed compare>| // this line dose not perform //any command, it is used only by the simulator for //testing that the divide operation was performed //properly

Algebraic program (AL):

A= #1 « 16;

|asm: rpt #14>|;

|asm: subc var3,a>|; // result in register a LL program:

Ld #1 , 16, a //A= #1 « 16 rpt #14 subc var3,a // result in register a

Example 3: HL: res = (round(clip(sum)))»16;

This may be written in the ML syntax as:

|{res = (round(clip(sum)))»16}||<a=sum, |asm:sat a | , |asm: rnd a | , res = a»16 >|; |<a{=res}>|; |<!Mixed compare>|

Algebraic code (AL):

a=sum;

|asm:sat a | ; |asm: rnd a | ; res = a»16 ; LL expression:

Ld sum, a

Sat a Rnd a

Stl a, res

1.8.2.4.2 Separate LL and HL Language expressions intervals

In some cases when it is preferred to separate the HL and LL expressions or subroutines or program the comparison between the HL and LL programs may be performed by specify desired location where the two program will be compared, for example after return from utility that calculated a polynomial. The exact comparison mechanism is described below:

HL program:

At desired locations in the program it is marked as: Ml_cmp(index, HL_var_to_compare, size);

Where index represent the serial number of the specific comparison location HL_var_to__compare is the name of the variable to be compared Size is the number of elements to be compared

HL Example:

Vart = var2+var3; Ml_cmp(1 ,Var1 , 1 ); // comparison number 1 :

// compare Vart of size 1 Varδ = vart * var2; MI_cmp(2,Var5, 1 ); // comparison number 2:

// compare Varδ of size 1

LL program:

At desired locations in the program it is marked as:

Ml_cmp(index, LL_var_to_compare, size);

LL Example:

Reg_a = var3;

Reg_a = var2+Reg_a;

MI_cmp(1 ,Reg_a,1); // comparison number 1:

Branch lablel // compare Reg_a of size 1 Reg_a = Reg_a * var2;

Varδ = Reg_a

MI_cmp(2,Varδ,1); // comparison number 2:

// compare Varδ of size 1

lablel :

MI_cmp(100,Var101 ,1); // comparison number 2:

The programs are compiled and the 'MI_cmp(index,LL_var_to_compare,size);' expressing are marked as simulator expressions only - only the simulator/ emulator see and use them.

Simulator:

The simulator save for each Ml_cml point a arrivaI_counter which counts the number of times that the program passed in this specific Ml_cmp point. The Simulator executes the HL and LL programs, when arriving a comparison point the simulator waits that the second program arrives to the nearest comparison point.

When arrived then the simulator perform the following comparisons:

If the index of the two comparison point is equal, and the arrival_counters of the two points are equal { the simulator compares the variables values to be compared if the values are not equal then the simulator is halted and/or error message is reported

} else

{ the simulator is halted and/or error message is reported

} Example:

In the above example the simulator arrive to the Ml_cmp number 1 of the HL program and wait there. While the HL program wait, the LL program continue to be execute and when it reach Ml_cmp then it stops and the indexes of the Ml_cmp points is compared:

Lets assume that the two indexes are '1 ' and the arrival_counters are equal. Then Vart is compared to Reg_a and if the values are not the same then error message is reported or the simulator halts. Next the HL program arrive to Ml_cmp number 2 and wait until the LL program arrive to Ml_cmp point.

In the example there is an extra branch to lablel , and therefore the LL will stop at Ml_cmp point which is not number 2 and the simulator will halt and/or send error message.

1.8.3 Functions and Functions Parameters This section defines the method used to pass parameters from the calling program to the called routine. The declaration expressions define the variable/variable type and the register used to pass the parameter. The syntax defines:

routine definition: in the routine file, which parameters pass by which LL program parameter;

routine external declaration: in the calling routine file, what parameters pass by what LL program parameter;

routine entry point: the declaration syntax at the entry point of the routine defines the HL type, parameter name, register used to pass the parameter;

return command: If the routine return a value then in what register dose it return; and

the calling command to the routine.

The definition of the routine syntax: i) Routine declaration:

This declaration is used in the file that contains the routine. The syntax of the declaration:

|<reg1>||{type1}| subroutine_name(|{type2}||<reg2>|, ...);

This declares that the first parameter that pass is of type 'type2' and the value passes in register reg2 and the same is valid for more parameters. The return value is of type 'typel' and it returns in register .'regl'.

The translation to the HL, algebraic and LL expressions is as followed:

High-level: typel subroutine_name(type2, ...);

Algebraic code (AL): .def subroutine_name

// I<reg1>||{type1}| subroutine_name(

I{type2}]|<reg2>|, ...);

Low-level: .def subroutinejiame

// | reg1>||{type1}| subroutine_name( |{type2}||<reg2>|, ...);

The Low-level and Algebraic code translation includes also the ML definition in remark.

ii) Routine external declaration:

This declaration is used in the files that refer or call to the routine. The syntax of the declaration: 6

•Extern |<reg1>|[{type1}| subroutine_name(|{type2}||<reg2>|, ...);

This declares that the first parameter that pass is of type 'type2' and the value passes in register reg2 and the same is valid for more parameters. The return value is of type 'typel' and it returns in register

'regl'.

The translation to the HL, Algebraic and LL expressions is as followed:

High-level: Extern typel subroutine_name(type2, ...);

Algebraic code (AL): .ref subroutine_name

//Extern I^<reg1>||{type1}| subroutine_name(|{type2}||<reg2>|, ...);

Low-level: .ref subroutine_name

//Extern |<reg1>||{type1}| subroutine_name(|{type2}||<reg2>|, ...);

iii) Routine entry point:

This declaration is used in the same location that the HL program would declared it. The syntax of the declaration:

|<reg1>||{type1}| subroutine_name(|{typ2e var2}||<reg2>|, ...)

This declares that the first parameter that pass is Var2', it's type is 'type2' and the value passes in register reg2. The same is valid for more parameters. The return value is of type 'typel' and it returns in register 'regl '.

Note that the register that passes the parameter may be an expression or expressions separated with a comma as described in section 1.8.2.3 such as:

|< expression , expression , ... >|

This syntax is used at the entry point of the routine, and the translation to the HL, Algebraic and LL expressions is as followed:

High-level: typel subroutine_name(type2, ...)

Algebraic code (AL): subroutine name: //|reg1>||{type1}| subroutine_name(|{typ2e var2}||<reg2>|, ...)

{

routine commands

Low-level: subroutine_name:

//|reg1>||{type1}| subroutine_name(|{typ2e var2})|<reg2>|, ...)

iv) Calling routine:

Dst_expression = subroutine_name(par_expression,.., par_expression The relation to this syntax is as:

Dst_expression = function of source parameters

Thus, 'par_expression' is one of the ML expressions presented in 'Expressions on the right side of the equation' (section 1.8.2.1) or 'LL Expressions' (section 1.8.2.3) of 'ML Basic Expressions', where the result of the expressions is in the register defined in the routine definition of the specific parameter. The Dst_expression may be according to 'Expressions on the left side of the equation' (section 1.8.2.2)

General Example:

|<{Var1}=reg1>| subroutine_name(|<reg2={var2}>|,..,|<reg3{=var3}>[...);

where reg1...reg3.. are registers.

Before the call is performed the following arguments are prepared:

- Variable Var2' is loaded to reg2 - Second argument no operation is performed since Reg3 is expected to be equal var3 (refer to section 1.8.2.1).

- The return value is in regl Regl value is copied to vart .

The translation of example 1 :

High level:

Vart = subroutine_name(var2,.., var3...);

Algebraic code (AL): regl = subroutine_name((reg2=var2),..,reg3,...);

Var1=reg1;

Low-level: Ld var2, reg2 Call subroutine name

Stl reg 1, Vart

Example 2:

calling routine command::

|<{Var1}=a>| = subroutine_name(|<(a =var2) + var3>||{var2+var3}| , ,)<b{=var3}>|);

HL command:

Vart = subroutine_name(var2+var3, var3);

Algebraic command (AL):

a = subroutine_name((a =var2) + var3) , b);

vart=a;

LL command

Ld var2, a // prepare the first argument: (a =var2) + var3

Add var3, a

// second argument Var3' is already in register 'b'

Call subroutine name // the return value from the

//subroutine is in register 'a'

stl a, vart

v) Return command:

return(|<expression>|); The return command verifies that the return value will send to the calling program in the specific register defined in the routine definition.

For example in the example below the value of variable Var' is moved to the register 'reg' before return to the calling program:

return(j<reg={var}>|);

If the returns register already contain the result then the following may be applied:

return(|<reg{=var}>|);

1.8.4 Conditional expressions use in conditional instructions:

1.8.4.1 General Syntax: The conditional expressions basic syntax:

'expressionl' 'operator' 'expression2'

Where 'expressionl' and 'expression2' may be any expression as described in ML Basic Expressions (section 1.8.2) and 'operator' is any of the high level language relational operators: '=>', '=<'-, '>' and '<' or equality operators: '==' and '=!'.

Number of conditional expressions:

The conditional expression may be conduct from a number of expressions:

('exprt' 'opert' 'expr2') log_oper1 ('expr3' Oper2' 'expr4') log_oper2 ...

where exprt..4 are expressions, opert ..2 are relational operators or equality operators, and log_operl.2 are logical operators.

The evaluation order of the conditional expression may be significant since the expressions may include incremented pointers or some other parameters or registers that may pass between the expressions. Thus the evaluation is performed from left to right, i.e. the order of evaluation is: exprt is evaluated first, second is expr2 followed by 'operl ', and next is expr3 and expr4 and Oper2'.

1.8.4.2 ML Implementation

> The HL conditional instruction: that uses the conditional expression may be for instance the conditional branch:

If (expressionl > expression2)

is translated to the ML syntax as:

If ([{expression 1 > expression2}||<cond: operationl , operation2,... >|)

}

Where the 'operationl, operation2,...' are the algebraic operations which effect the condition 'cond'.

Example:

The HL expression:

If (x > y*2)

May be translated to ML expression:

If (|{x > y*2}[|<a>0 : a=x, a=a-y«1>|)

The algebraic expression: If (a>0 : a=x, a=a-y«1)

The LL code then is:

Ld x, a

Sub y,1 ,a

Be label, aleq

If a number of comparison expressions are included then the ML order of evaluation is performed according to section 1.8.7.1 'order of evaluation'.

If the operations are not needed, since they were perform previously then the following syntax may be apply:

If (|<(cond=AOV)>||{the original HL expression}!) // condition is AOV

For example:

Sum = 0;

For (l=1;K100;l++)

Sum = Sum+array[l];

If (Sum>SAT_VALUE)

Sum = SAT vALUE;

The summation on array[] may produce overflow in 'Sum' that is detected by the condition (Sum>SAT) and perform clipping of the value of 'Sum'.

The Mixed Language of the above may be:

|{Sum= 0}|;

|<ar1 = &array[0]>|;

|{For (l=1;K100;I++)}||<rptz(a,99)>j |<Sum{a}>| = |<a{Sum}>|+|<*art+{=array[l]}>|;

If (|<(cond=AOV)>||{Sum>SAT_VALUE }|) // condition is AOV - overflow //in accumulator 'a'

|<Sum{a}>| = SAT VALUE;

|<Sum - a>|;

The algebraic presentation (AL):

art = &array[0];

|{For (l=1;K100;l++)}||<rptz(a,99)>|

a = a + *art+;

If (cond=AOV) // condition is AOV - overflow in accumulator 'a'

a = SAT VALUE;

Sum = a;

LL program:

Stm #array, art // art = &array[0]

Rptz a, 99

Add ^*ar1 +, a // a = a + *art +;

Be no_sat, ANOV// If (cond=AOV) - condition is AOV - overflow in //accumulator 'a'

Ld #SAT_VALUE,a // a = SAT VALUE

No sat:

stl a, Sum // Sum = a 1.8.5 Loop commands:

1.8.5.1 Repeat one instruction 'num_ f_repeatitions' times: Repeat one instruction command is used when the number of repetitions is known or may be calculated before loop start and it may be represented by the 'rpf command. For example according to the 'TI mnemonic instruction set', the 'rpf command argument may be constant or memory variable, thus the repetition times has those two options, and the ML syntax for the 'rpf command:

|<rpt (num_of_repetitions : expression);* j j{for(initialization ; condition ; action)}|

where 'num_of_repetitions' is the number of repetition of the loop, and the 'expression' is optional and used in the case that 'num_of_repetitions' has to be calculated.

Example:

• If the number of repetitions is a constant, like NUM_OF_REPETITION that is defined in the program then the following is applied:

the HL command: for(i=0;i< NUM_OF_REPETITION;i++)

may be presented in the ML program as:

|<rpt (#NUM_OF_REPETITION-1)>| |{for(i=0;i< NUM_OF_REPETITION;i++)}|

The Algebraic command (AL): rpt(#NUM_OF_REPETITlON-1)

The LL command: rpt #NUM_OF_REPETITlON-1 • If the number of repetitions is an expression: '(vart* 2+10)', then the number of repetitions has to be calculated in the 'expression'. For example:

The HL command: for(i=0;i< (vart * 2+10) ;i++)

In the ML command, the expression Var1*2+10' has to be calculated and the result has to be referred by the 'rpf command:

|<rpt (*(al): a=var1«1 , a=a+9)>| |{for(i=0;i< (vart* 2+10)

Where the '(*al)' (the content of accumulator a low) represents the 'num_of_repetitions' and the 'a=var1 «1 ,a=a+9' represents the 'expression'.

The Algebraic expression (AL): rpt (*(al): a=var1«1 , a=a+9)

LL expression: Id vart , 1 , a

Add #9, a

rpt (*(al))

1.8.5.2 Repeat one instruction 'num_of_repeatitions' times with zero register 'reg':

The Repeat one instruction 'num_of_repeatitions' times with zero register 'reg' syntax is the same as the 'rpf command described in section 1.8.5.1 , with one difference that is the specify of the zeroed register.

|<rptz (reg, num_of_repetϊtions : expression)>| |{for(initialization ; condition ; action)}|

1.8.5.3 Repeat block of instructions 'num_of_repeatitions' times:

)<brc = expression^ ;

|<rptb>| |{for(initialization; condition;i++)}| { command lines instruction

} ^'

Note that the 'rptb' command parameter for the number of repetitions is the register 'brc', that has to be set before the 'rptb' command.

Example:

ML program |<brc =TAPS-1

|<rptb>| |{for(i=0;i< TAPS;i++)}|

HL program: for(i=0;i<TAPS;i++)

Algebraic program (AL): |<brc =TAPS-1 >|;

rptb

LL program: stm #TAPS-1, brc // |<brc =TAPS-1 >|;

rptb label

1.8.5.4 'for' loop command 1 :

This syntax is used when the special repeat blocks commands of the LL are not used.

For(initialization; condition; execution)

Repeated_operation where initialization, condition and execution may be any ML expression or expressions like '|<a=i, a=a+1 , i=a>||{i++}|' in the example below.

The LL translation of "for' loop command 1' is:

initialization; // execute initialization command sequence

if condition==false then skip loop (*)

Repeated_operation

execution - // execution commands sequence

if condition==true then repeat loop // condition sequence

}

Note that the 'execution' and 'condition' are implemented in the low-level program in concatenation, and in the beginning of the loop the 'initialization' and the 'condition' are concatenation. Thus the 'execution' may prepare the parameter in, register for the 'condition', and the

'initialization' may prepare the parameter in register for the 'condition'.

In some cases when it is known that the loop is executed at least one time, then the entry loop condition, marked line with (*), may be unnecessary (for optimization purpose). This is done by using ]<!for skip entry cond>| at the Mixed Language 'for' statement line.

Example:

HL language:

for (i=0; i <= 10 ;i++)

{ vart = vart+i;

ML language:

for (i =0 ; |{i<=10}||<b<=0: (b=a-10) >| ; )<a=i, a=a+1 , i=a>||{i++}|) |<!for skip entry cond>|

{

!<{var1}=a>) = |<a{=i}>|+ vart ;

Algebraic code (AL):

i = #0;

{

Loop:

a = vart+a;

vart = a XI |<{vart}=a>| = //vart+|<a{=i}>|;

// perform the 'j<a=i, a=a+1 , i=a>|' form the 'for' command line

a=l;

a=a+1;

i=a;

// perform '|{i<=10}||<(b=a-10) <= 0 >|' form the

'for' //command line

b = a-10; if b<= 0 then br Loop

}

LL code:

St #0, i ll\ = #0

//{

Loop:

Add vart , a //a = vart +a;

// perform the '|<a=i, a=a+1 , i=a>|' form the 'for' command //line

Id i, a //a=i

add #1 , a //a=a+1

stl a, i - //i=a = i=i+1

// perform 'l{i<=10}||<(b=a-10) <= 0 >|' form the

'for' //command line

sub #10, a, b //b = a-10

be Loop, bleq

//}

1.8.5.5 'for' loop command 2:

The "for' loop command 2' perform the condition test at the start point of the loop, and at the end of loop branch to the start point. In order for the Compiler to translate the 'for' loop in command 2 mode the ]<for entry loop cond>| has to be added at the Mixed Language 'for' line.

For(initialization; condition; execution) |<!for entry loop cond>|

{

Repeated__operation

}

The "for' loop command 2' is translate to:

initialization; // execute initialization command sequence

{

loop:

if condition==false then branch loop_exit

Repeated_operation execution // execution commands //sequence

execution

Branch loop

loop_exit:

Note that the 'execution' and 'condition' are implemented in the low-level program in concatenation, and in the beginning of the loop the 'initialization' and the 'condition' are concatenation. Thus the 'execution' may prepare the --.„--,,

PCT/IL2003/000851

101 parameter in register to the 'condition', and the 'initialization' may prepare the parameter in register to the 'condition'.

1.8.5.6 'WHILE' loop command 1 :

The 'while' loop command high-level language syntax:

while(condition)

Repeated_operation

Is translated to the Mixed Language similarly as in the 'for' command:

while(Mixed_Language_condition)

Repeated_operation

The translation to low-level language is:

If (Mixed_Language_condition==FALSE) then branch loop_exit (*)

loop:

Repeated_operation

If (Mixed_Language_condition==TRUE) then repeate loop --.„--,,

PCT/IL2003/000851

102

loop_exit:

In some cases the entry loop condition, marked line with (*), may be unnecessary (for optimization purpose). This is done by. using |<!while skip entry cond>| at the Mixed Language 'while' statement line.

Example:

HL program::

n=0;

delta = 1;

while(delta > 0)

{

delta = array[n]-var1 ;

n=n+1;

The translation to ML:

|<ar1 = &array[0]>|;

|<ar2{n}>| = 0;

|<b{delta}>| = 1;

|<a=-var1>|;

while(|<b{=delta}>| > 0) l<!while skip entry cond>| |<{delta}b>| = I<*ar1+{=array[n]}>|+|<a{=-var1}>|; |<{n}ar2>|= |<ar2{n}>|+1;

The translation to low-level language:

Stm #array, art // |<ar1 = &array[0]>|

Stm #0, ar2 // |<ar2{n}>| = 0;

Ld #1, b // |<b{delta}>| = 1 ;

Ld vart , a

Neg a // |<a=-vart>|

// while(|<b{=delta}>| > 0) |<!while skip entry cond>)

//{

loop:

add *art+, a, b //|<{delta=}b>|=

//|<*ar1+{=array[n]}>|+|<a{=- vart}>l;

mar *ar2+ //|<ar2{=n}>|= |<ar2{=n}>|+1 ;

be loop, bgt // the 'while' condition |<b{=delta}>| > 0

//}

1.8.5.7 'WHILE' loop command 2: ■The 'while' loop command 2 perform the condition test at the start point of the loop, and at the end of loop branch to the start point.

In order for the Compiler to translate the while loop in command 2 mode the |<while entry loop cond>| has to be added at the Mixed Language 'while' line.

The high-level while command syntax:

while(condition)

Repeated_operation

Is translated to the Mixed Language:

while(Mixed_Language_condition) |<!while entry loop cond>|

{

Repeated_operation

The translation to low-level language is:

//{ // start of loop

loop:

If (Mixed_Language_condition==FALSE) then branch loop_exit

Repeated_operation

Branch loop loop_exit:

1.8.5.8 Loop operation with separation of the of the HL expressions from the LL expressions

In some cases the loop syntaxes presented in section 1.8.5.1-7 are preferred not to be used, then a separation of the HL commands from the LL commands may be performed by surround the HL expressions with |{...}| and surround the LL expression with |<...>| or with |asm:...>|. Rules presented in section 1.8.2.7 'Separate LL and HL Language expressions'

For example:

HL command:

for(l=0;K10;l++)

{

expressions

}

ML command:

|{for(l=0;X10;l++)}|

{

expressions

|asm: banz loop, *art- >|; // if art !=0 then branch loop

} --.„--,,

PCT/IL2003/000851

106

1.8.6 Variables declaration:

This section presents the options for variable and vectors declarations. The translation to LL variable declaration is according to the LL syntax using 'sect' or 'used' directives for initialized or un-initialized variables.

In the below:

'type' - is the HL variable type eg short, long etc. Var' - is the variable name

'section_name' - is the section that the variable will declared in. 'allocation lags' - are the allocation flags used by the LL builder, eg. Alignment, each processor may has different allocation flags and different allocation flags syntax.

1.8.6.1 Variable allocation Assign variable 'var' to section 'sect_name'. Other assign options may be added as appears in the low-level language syntax.

type vart ,var2|<(sect"section_name",allocation_flags)>|;

1.8.6.2 Vectors allocation type var[size]|<(sect"section_name" , allocation_flags)>|;

type var[size1][size2]|<(sect"section_name" ,allocation_flags)>l;

1.8.6.3 Initialized variable/vectors allocation

Declaration and initialized variables and vectors syntax:

type var=value|<(sect"section_name" ,allocation_flags) >);

where 'value' is the initialization value of the variable 'var'.

type var[size]={item1, item2,...} |<(sect"section_name" ,allocation_flags) >|;

where 'item 1/2/...' are the initialization values of the buffer 'var'. 1.8.6.4 Variable - External declaration

External declaration has type but in assembler it's converted to 'global'.

External type var_name

1.8.7 Mathematical Expressions:

1.8.7.1 Order of evaluation/execution:

High-level language, like C, defines some rules concerning the order of evaluation of mathematical expressions, like *,/ and % have the same precedence that is higher then -,+. The Mixed Language apply those rules but in order to ensure proper operation more rules has to be apply because of the below reasons:

some cases are not defined and handled by the Ansi-C. For example the expression:

Var1[n] = n~;

May produce different result in different compilers, since it is not clear when to modify 'n', before the store or after the store operation;

another example is the use of pointers:

Short *a_pnt;

Short a[10];

a__pnt = &a[0];

^* a_pnt = (*a_pnt ++) + (^*a_pnt ++) ^* 2; The result value evaluation in the last line is not clear (depends which memory cell will be multiply by 2). Moreover, it is not clear where dose the operation result is stored, in the original 'a_pnf before incremented or after 'a_pnf is incremented.

In low-level language programming the use of pointers is very common and the order of execution has a major significance.

Thus an evaluation order in Mixed Language is apply:

1. The evaluation order in the Mixed Language agrees with the high-level language evaluation order. For example the Ansi-C precedence and order of evaluation rules.

2. The right side of the equation is evaluated first. The left side of the equation is performed second.

For example:

The high level language line:

*a_pnt = (*a_pnt ++) + 2;

The translation to Mixed Language may be:

|<{*a_pnt} *ar1=a>| = |<a=(^*ar1+){=(*a_pnt ++)}>| + 2;

In low-level implementation first the '(*a_pnt ++)' is performed and then the store operation is performed:

Id *art+, a

add #2, a

stl a, *ar1

3. On the right side of the equation: If the high-level language dose not defines order of evaluation then execute the calculation left to right. 4. On the left side of the equation: If the high-level language dose not define order of evaluation then execute the calculation right to left that is from the '=' sign to the left direction.

5. If it is decided that the equation right side order of evaluation is not important and the compiler may find the best execution order for best optimization then the remark |<!order insignificant^ may be added to the specific expression line, (the left side of the equation is performed always right to left).

6. If it is decided that the equation right side order of evaluation is important then the ML syntax may impose the order of evaluation between items that has the same priority. This is done by specify the priority as followed:

Where:

execution_order - are serial numbers from 1,2,

The expression which has 'execution_order'=1 is the first to be execute, the expression that has 'execution_order'=2 is the second to be execute and then the operation is perform between these two.

Operation - is mathematic operation like '+', '-' and so on.

Refer to example 3 below.

Example 1:

The high-level language command:

vart = 1;

*pnt1++ = *pnt1*2 + vart + var2; Where pntl points to the address of the memory.

Mixed Language:

|<{Var1}=b >| = 1; (1)

|<art = pnt1>|; (2)

|<{*pnt1+}(*ar1+)=a>| = |<a=*art{=*pnt1}>| * 2 + |<b{=vart}>| + var2; (3)

low-level language:

ld #1, b //b = 1 // perform (1) left side

//of the equation right to left

mvdm pntl , art // art = pntl

Id *ar1,1, a // a = *ar1 «1 // perform (2) right side

//of the equation left to right

add b, a // a = a + vart

add var2, a // a = a + var2

stl a, *art+ //*pnt1 = ajow

//pntl = pntl +1

example 2:

Example 1 Mixed Language may be written in more efficient optimized way by using the register 'b' which contains 'vart' value. This is enabled by adding |<!order insignifιcant>| (described in section 1.8.7.1 /5) at the line of (3). This optimization is performed by the compiler. The high-level language command:

vart = 1;

*pnt1++ = *pnt1*2 + vart + var2;

Where pntl points to the address of the memory.

Mixed Language:

|<{Var1}=b >l = 1; (1)

|<ar1 = pnt1: (2)

|<{*pnt1+}(*ar1+)=a>| = |<*art{=*pnt1}>| * 2 + |<b{=var1}>| + var2; |<!order insignificant>| (3)

low-level language:

ld #1 , b //b = 1 // perform (1) left side

//of the equation right to left

stl b, vart //varl = b

mvdm pntl, art // art = pntl

add *ar1 ,1, b // b = b+ *ar1 «1 // b = varl +

*pnt1 *2

add var2, a // a = a + var2

stl a, *art + //*pnt1 = ajow

//pntl = pntl +1

Example 3: Example 3 refers to item 6 of the evaluation order in Mixed Language above. The order of evaluation is set in the ML syntax:

The high-level language command:

vart = 1;

*pnt1 ++ = *pnt1*2 + vart + var2;

Where pntl points to the address of the memory.

Mixed Language:

|<{Var1}=b >| = 1; (1)

|<art = pnt1>|; (2)

|<{*pnt1++^'}(*ar1+)=a>| =|2<*ar1{=*pnt1}>| *2 + |1 <b{=var1}>| +

|3<{var2>|;(3)

Note that the order of evaluation is set from 1 to 3 in the '|order<' (marked with underline)

low-level language:

Id #1 , b lib = 1 // perform (1 ) left side

//of the equation right to left

stl b, vart /Vart = b

mvdm pntl , art // art = pntl

add *ar1 ,1 , b // b = b+ *art «1 // b = vart + *pnt1 *2

add var2, a // a = a + var2

stl a, *ar1 + //*pnt1 = a

//pntl = pntl +1 1.8.8 Addressing modes:

Direct mode : use prefix @ or no prefix

Indirect mode : use @@

1.8.9 Include, Files

Include files: In the high-level language program there are two types of include files, the first is the include files used by the high-level language (like stdio.h in C), and the second is the project specific include file which defines constants etc.

Since the low-level language need only the specific project include file then they are marked with addition |<!proj include>| added after the #include command.

Example:

ML syntax:

#include <stdlib.h>

#include "ecdef.h" |<!proj include>|

Only the Include 'ecdef.h' line has to be used by the low-level language and this line is marked with '|<!proj include>|'.

HL program:

#include <stdlib.h>

#include "ecdef.h" LL and algebraic programs:

.include "ecdef.inc"

1.8.10 Latency handling

If there is low-level language command that has latency restrictions then the Mixed Language program, has to be written according to the restriction.

For example a conditional command that is executes according to a comparison result that is performed at least two cycles before. This command may be handled in the following:

HL expression:

If (cond = condition_expression)

expression

ML expression:

|< cond = condition_expression >|;

expression that takes at least two cycles

|<if (cond)>||{if (condition_expression)}|

expression

}

Example: High-level:

If (x> 1000)

x=1000;

Mixed Language:

|<cond = expression describes (x>1000) >|; // the condition result

//will be used later

other at least two cycle instruction/s

|{ lf (x>1000)}||<if (cond)>|

x=1000;

Example:

The 'xc' command needs that the comparison result will be ready two cycles before the 'xc' command. Thus the comparison is performed two cycles before the 'xc command which is marked with '|<use xc 1 ,b>|'

Example:

High-level:

Vart = var2«1;

If (x<2) y=i ;

Mixed Language commands:

|<cond = (((b=x)-2))s

|<{Var1}=a>| = |<a={var2«1}>|;

// two command for the latency restriction

|{lf (x < 2)}||<if (cond=(b<0))>| |<use xc 2,cond>|

y = i ;

The Algebraic code (AL):

b = x; //|<cond = (b=((b=x)-2) < 0)>|

b = b-2; //condition result is located in register 'b'

// and the condition is 'blf (b less then)

// two command for the latency restriction

a = var2 « 1 ; //|<{Var1}a>| = |<a={var2«1}>|;

vart = a; //|<Var1=a>|

if (cond=(b<0)) |<use xc 2,cond>|

{

y = i ; 1.8.11 Delayed instructions

Delayed instructions are usually branches. The insertion method of delayed branches is :

1. Multiply the branch command (like in the below example),

i) The original 'if command is surrounded by |{if( .. )}|

ii) the multiplied 'if command has to be written two cycles before the 1.a 'if command, surrounded by |<if( .. )>|

iii) Inform the compiler that the line written in lb is a delayed branch by write '|<delayed branch>!' after the '|<if( ..

^)>F • 2. Between the two 'if command (in a and 1.b) there must be two cycles command for proper operation of the program.

3. The main principal that has to be taken care is that if the program is separated for high-level language program and low-level language program then the both program will perform the desired operation.

Example: Below is an example for delayed branch

HL program:

Var0 = Var0+100;

Vart = Var2«2;

If (vart >10000)

Var2 = 100;

}

The Mixed Language is composed of duplicated 'if command, one is surrounded with |<if(..)>| (marked as low-level command), and the second is surrounded with |{if(..)}| (marked as high-level command), while between the two command there is two cycles command that is marked to use 'addm' in the low- level command.

ML program:

|<{Var1}= a>| = Var2«2;

|<If (a>0: a=a-1000 ) >|; |<!delayed branch>|

Var0 = Var0+100; |<!use addm>| // the programmer has to

//ensure that this line is two cycles

|{If (var1>10000)}| // the original HL conditional branch

{

Vart = 10000;

Var2 = 100;

Algebraic program (AL):

a = Var2«2; // |<{Var1}= a>| = Var2«2;

vart = a; lf (a>0: a=a-1000 ) |<!delayed branch>|

Var0 = Var0+100; |<!use addm>| // the programmer has to //ensure that this line is two cycles

//|{lf (vart >10000)}| //the original HL conditional branch

Vart = 10000;

Var2 = 100;

program:

Ld Var2 , 2, a // |<fVar1}= a>| = Var2«2;

Stl a, vart

Sub #10000, a

Bed lable, leq //If ((a=Var1) >10000) |<!delayed branch>|

Addm #100, var0 /Var0 = Var0+100;

//|{lf (vart>10000)}| // the original HL conditional branch

//{

st, #1000, vart // Vart = 10000;

st #100, var2 // Var2 = 100;

//}

Lable: Example for delayed return command:

The routine adds 3 to the input parameter Vart and returns the result.

High-level language routine:

short routinel (short Vart)

short var2;

Var2 = var1+3;

Retum(Var2);

} //end of routine

ML routine:

|<a>||{short}| routinel (|{short Var1}||<a>|)

|<retum>|; |<!delayed retum>| // delay return that will be execute after two

// cycles

|<a{var2}>| = |<a{vart}>|+3;

|<nop>|;

|<a{=var2}>|; |<Mixed compare>| // comparison that the return value //(reg 'a') is equal to the expected return value (var2). This is executed only by the //development tools |{return(var2)}|; // command marked with |{ }| thus will be

// refer only in the high-level language program.

} //end of routine

LL routine:

//|<a>||{short}| routinel (|{short Var1}||<a>|)

routinel:

//{

retd //|<return>|; |<!delayed return>| // delay return that will be //execute after two cycles

add #3, a //|<a{var2}>| = |<a{vart}>|+3;

nop

//} //end of routine

1.8.12 Shortened HL expressions

There are some HL expressions that are difficult to express in the ML syntax, these expressions like:

- (a>b) ? c : d

- division: C = A/B; or other.

In this case it is recommended to re-write the expression not in the shortened presentation, like: (a>b) ? c : d may be written in as: if (a>b) {

} else

{ d

} and then implement the ML syntax.

If the HL expression may not written in the shortened HL expression, like the division operation: C = A/B;

Then the expression may be handled as described in the section 1.8.2.4 'Separate LL and HL Language expressions'.

1.8.13 Push and Pop:

Push and Pop are done using special command:

Save_reg(reg1 , reg2, accumulator! ...);

Is converted to:

Push regl

Push reg2

Push accomulatort low

Push accomulator1_high

Push accomulator1_guard

Restore_reg(reg1 , reg2, accomulatort ...); Is converted to:

Pop accomulator1_guard

Pop accomulatort _high

Pop accomulatortjow

Pop reg2

Pop regl

1.8.14 Low-Level Language specific expression

Every processor has it's own command set that include regular operation, like store, add etc., and special command which handles special processing cases, like the Tl's DSP tms320c54 LMS command which handles least mean square algorithm, or commands which perform store operation according to condition (used for table search) and more other commands.

If one of the special commands are to be used or a specific low-level command or commands are to be used then:

- A special syntax may apply to the Mixed Language, similar to the special syntax presented for the 'loop' commands in section 1.8.5 'Loop Commands'.

- If no special syntax is included for the special operation, then the ML expression is preferably written according to the section 1.8.2.4 'Separate LL and HL Language expressions'

1.8.15 Special words:

High-level language variables may not have names of the low-level reserved words (like registers). This is since the Mixed Language syntax includes high-level program mixed with low-level program and there may be confusion if the high-level variables have the low-level language reserved words.

1.9 Rules - Mixed Language Implementation Cases

The mixed language system may include various implementation cases. Some of them are described in this section.

1.9.1 C and ML in same program\ functions

In some cases it may be preferred to create a program that include HL expressions, such as C, and mixed-language expressions, such as assembly. These cases are useful for example when only a part of the program has to be optimized, and the main benefits of such SW configuration is the automatic errors detection, ineligibility and other.

The structure of such implementation case is described in the following example.

Example - consider the following SW flow structure:

HL expression/s 1 (C expression)

HL expression/s 2 (C expression)

HL expression/s 3 (C expression)

ML expression/s 4 (which describe C and assembly code) HL expression/s 5 (C expression)

HL expression/s 6 (C expression)

Compiler operation:

The compiler output is two programs: - First output program coded in the first program language, optionally assembly, and which will be run on the predetermined target processor. - Second output program - coded in the Second program language, optionally C, and is the reference program that is used to verify the operation of the First output program.

The second output program is the result of HL expressions, which consist of the original HL expression/s and the HL expression/s extracted from the ML expression. This second program may be compiled by:

- The target processor compiler

- Any other adequate HL compiler Example:

The below example describe the operation method wherein the first output program is encoded in LL language, and the second output program is encoded in HL language.

In other cases the first and second output programs may be encoded in any other language such as both in C or any other combination.

The following table describe the input file is the Mixed-language program (0), which consists of HL and ML expressions. The compiler processes this file and outputs:

- first output program (1) encoded in the first language, optionally LL.

- second output program (2) encoded in the second language, optionally HL.

The first output program (1) consist of:

- (3) LL expressions 1, 2, 3, δ, 6 are result of the target processor compiler and optimizer, this code is to be run on the target processor environment (with the 'LL expression 4').

- (4) LL expression 4 extracted from the 'ML expression 4' by the ML compiler according to the ML rules and is to be run on the target predetermined processor. second output program (2) consist of:

(δ) HL expression 1 ,2,3,6 and 6 are the original expression from the Mixed-language program (0).

(6) HL expression 4 is expression in the second language coded in HL, that was extracted from the 'ML expression 4' by the ML compiler according to the ML rules.

The Second output program (7),which is used to test and verify the First output Program operation, may be compiled by: the predetermined processor compiler(δ) resulting LL_T expression 1-6 (10), or by

- any other adequate compiler (9) such as Ansi C compiler Microsoft C compiler, Borland C compiler or the compiler that was used to develop the implemented SW algorithm, resulting LL_A expression 1-6 (11),.

There are several options for the predetermined processor compilation such as: - LL_T expressions 1 , 2, 3, 5, 6 are the same as - LL expressions 1 , 2, 3,

5, 6

And the LL_T expression 4 is result of compiling HL expression 4 where the copiler takes into consideration the resources used by the LL_T expression 1 , 2, 3, 5, 6 - this is in order to prevent any conflict of the resources used in the LL_T expression. .

- LL_T expressions 1 , 2, 3, 4,5, 6 are the result of HL expressions 1 , 2, 3, 4,5, 6 new compilation with no optimization.

The LL_A expression 1 , 2, 3, 4, 5, 6 (11) are the result of compilation of the HL program expressions: HL expression 1 , 2, 3, 5, 6 and the HL expression 4 (that was extracted by the ML compiler according to the ML rules), where the compilation performed by any adequate compiler such as Ansi C, Microsoft C or other.

Simulator operation

The simulator operation:

- Executes the target processor program

- Executes the Reference program

- While execution the simulator compare the operation of the two programs, searching for errors according the Simulator Error Detection chapter.

Example:

If the reference compiler selected is the Target processor compiler then the operations of the following expressions are performed: 'LL expression 1' is compared to 'LL_T expression 1' 'LL expression 2' is compared to "LL_T expression 2' 'LL expression 3' is compared to 'LL_T expression 3' 'LL expression 4' is compared to 'LL_T expression 4' 'LL expression δ' is compared to 'LL_T expression δ'

'LL expression 6' is compared to 'LL_T expression 6' and is error is detected then a message is reported.

If the reference compiler selected is the Ansi C compiler then the operations of the following expressions are performed:

'LL expression 1 ' is compared to 'LL_A expression 1 '

'LL expression 2' is compared to 'LL_A expression 2'

'LL expression 3' is compared to 'LL_A expression 3'

'LL expression 4' is compared to 'LL_A expression 4' 'LL expression δ' is compared to 'LL_A expression δ'

'LL expression 6' is compared to 'LL_A expression 6' and if error is detected then a message is reported.

Emulator operation: The emulator operation is the same as the simulator, and in additional the learning phase described in the Emulator Automatic Error Detection chapter.

1.9.2 Comparison of any HL expressions/programs Similarly to the mix of HL and LL expression, the mixed program may contain reference HL program and modified HL program.

In this case there are three types of expression: 1 ) Reference HL expressions, marked by special sign for example K }|

2) Modified HL expressions, marked by special sign for example ι< >l

3) Mix language system expression such as comparison commands in the below example the 'ml_compare' command compare the above expression results.

Example:

Vart = 100; // common to HL and LL

|{Var2 = 2^Λ1 δ/Vart ; }| // HL expression 1

|<for (l=0;K10;l++) >| // HL expression 2

|< Var2_ll = sub_carry(Var1_ll , 30); >| // HL expression 3

|< Var2_ll = (Var2_ll«δ) & Oxffff >| // HL expression 4 ml_compare(Var2_ll, Var2); // compare the results of the HL expression 1 :

// Var2 = 2^Λ1δ/Var1 to the results of the HL //_expressions 2,3,4

1.9.3 No bit-by-bit comparison

In some cases there is not bit-by-bit equivalency between the second output program (the reference program) and the first output program (the target program), which may be HL program and the LL program respectively. The non bit-by-bit equivalency may be true for a small number of HL lines commands or for subroutine or whole function, for example:

1) When equation output precision of the target program expression is different from the reference program expression.

2) A specific routine of some function dose not have the same result, when comparing the reference to the target programs routines. 3) On standard implementation - some of the standard (such as speech coders) do not require that the target program will have the same result as the original standard code. Therefore the target-implemented program has no bit-by-bit equivalency with the standard program.

In this case the comparison as described in the sections 'error detection' and the 'expression evaluation' should take place with two differences:

1) The new comparison criterion is that the target expression result is compared to a range of results numbers, instead an exact result in the bit-by-bit test case.

For example is the value calculated by the reference program is reference_val and the value calculated by the target program is target_val. Then the comparison criteria may be in respect to the ratio between the numbers and in consideration to the numbers absolute value, all according to the application, and the SW tested requirement.

Comparison example:

If (reference_val > energy theresh) and (minimum(target_val, reference_val) / maximum(target_val, reference_val))

< ratio_threshould then comparison result is OK or If (reference_val <= energy theresh) and (absolute (target _val - reference _val ) ) < mag hreshould then comparison result is OK in this example the comparison criterion depends on the value of the reference result reference_val. If reference_val exceed energy heresh then the criterion is ratio, otherwise the criterion is difference. ) Prevent divergence numbers comparison. This is usually the case when a close loop mathematical algorithm are compared, then small differences between the expected results are increasing as time/samples increases, resulting divergence behavior between the reference program and the tested target program.

In order to compare the programs and reduce or prevent the divergence problem, then the following should be executed: a. Before execution of the non bit-by-bit expression/s interval, the parameters for the tested expression/s should be loaded form the reference program to the tested program. b. Then execute the reference expression/s and the tested expressions. c. Compare the results of the reference expression/s and the tested expressions according to section (1) above.

Another option is:

1 ) Before execution of the non bit-by-bit expression/s interval, the parameters for the reference expression/s should be loaded form the tested program to the reference program.

2) Then execute the reference expression/s and the tested expressions. 3) Compare the results of the reference expression/s and

. the tested expressions according to section (1) above.

Example:

Consider the following expressions:

Var2 = 2^Λ1δΛ/ar1 ;

The ML program: Vart = 100; // common to HL and LL

|{Var2 = 2^Λ1δ/Var1 ; }| // HL expression

|<for (l=0;K10;l++) >| // LL expression

|< Var2_ll = sub_carry(Var1_ll , 30); >| // LL expression |< Var2_ll = (Var2_ll«5) & Oxffff >| // LL expression

Var4 = Var2*Var3;

In order to test the result of Var4 = Var2^*Var3

Note: If step 3 was not performed then the result of step 4 was that Var4 not equal to Var4_ll.

Step 3 enable to eliminate the error in Var2 produced in step 2.

1.9.4 Parallel processors implementation - mnemonic

Parallel processing units (such as VLIW dsp's) have the following properties:

Performing one or more operations in one core clock cycle. - Some operations commands have latency restrictions The ML implementation may be perform in a number of options: 1) Separate the reference program (such as C program) from the implementation program (such as assembly program), as described in section 'Separate LL and HL Language expressions'. 2) If the two programs (the reference program and the implemented program) expressions can be mixed according to the ML rules, then the rules may be applied with the following addition rules that specify for each operation: a. The calculation unit that performs the specific operation. For example if there are two multiplication units the compiler has to know which unit is to be used for the specific operation. b. When dose this operation be performed. This is important since: i. In order to overcome the latency restrictions ii. For parallel processing units

(such as ASIC) every operation has it's timing (usually according to the clock cycle).

Example: a. The attribution of HL operation has to be perform to one of the processor's calculation/operation unit, for example the expression: Vart * var2 include multiplication, and if the processor have two multiplication units

(M1, M2) and the desired unit to perform the operation is M2, then the

ML program specify that - for example:

Vart *|<M1>| var2 - specify that module M1 perform the multiplication between Vart and var2.

Specify the timing/location of the operation for the following ML expressions:

L1 : Vart = Var2 *|<M1 ,L1 >| Var3; Var4 = Vart *|<M2,L3>| Varδ; L2: Var6 = 1; L3: Var7 = Var2 *|<M1 ,L3>| Var6;

Execution order of the LL program:

L1: Vart = Var2 * Var3 perform in unit M1

L2: Varδ = 1

L3: Var4 = Vart *|<M2,L3>| Varδ; - perform in unit M2 on label

L3 due to multiplication latency of one cycle.

L3: Var7 = Var2 *|<M1 ,L3>| Varδ; - perform_, in the available second unit M1

1.9.5 Parallel Processing Units Implementation

In addition to the mnemonic development environment, the ML compiler may operate in graphical development environment and on parallel processors implementation environment. Such implementation casses starts with HL language (usually C ), which has serial program structure, while the target processor and SW has parallel structure -such as in VLIW or ASIC.

Parallel processor SW implementation using the ML method has the following steps: 1 ) Starting with input HL (C ) file (such as standards - JPEG etc.). Example:

Where C expression may be one or more expression/s subroutine etc.

2) The function implemented is converted and adapted to parallel structure according to the SW flow, compiled to result LL code, and tested by the target simulation program, such as ASIC simulation program.

Example:

The C expressions are adapted to simulate by the simulation program, are ordered according to their operation in the program flow and dependencies between their variables, and each expression is time marked according to it's execution timing

Execute Execute Execute attime tlO at time tlO at time tlO

C expre 1ssion 1 1 I ^' I

C expression 2 C expression 3

Execute C expression 4 attime τ20

Execute at time t30 C expression 5 ) ML modification:

LL expressions are added to the parallel HL structure. The result diagram describes for each HL expression/block its translation to the appropriate LL expression/s.

Then the implemented LL program /expressions are tested by the target simulation program, such as ASIC simulation program, which execute the HL and the LL expression and compare their operation - similar to the ML simulator operation descried in the Mixed Language Simulator Development Tool chapter.

Example:

In the example the new structure may contain LL modules that exist only for the LL expression and dose not. have HL compatible expression.

These modules may present FIFO, Serial 10 or any other module according to the application.

Claims

CLAIMS:

1. A computer-implemented method for generating a program in a first language compilable to run on a predetermined processor from a mixed-language program combining expressions of said first program language and a second program language, the method comprising: receiving as input the mixed-language program, that allows generation of a first program language according to a set of pre-determined rules; and generating an executable output program encoded in said first language.

2. The method according to claim 1 , wherein the mixed-language program comprises information, that allows conversion of the second program language to the first program language, according to the set of pre-determined rules.

3. The method according to claim 1 or 2, wherein the first language is low-level and instructions encoded in said first language are presented in structured algebraic form.

4. A method according any one of claims 1 to 3, further including generating from the mixed-language program at least one of the following additional output files:

(a) first output program file encoded in said first program language;

(b) second program output file encoded in the second program language;

(c) first output file encoded in the structured algebraic form; (d) Mixed language list file; and

(e) Any combination of two or more of (a) to (d).

5. The method according to any of claims 1 to 4, wherein the mixed language program is displayed in at least one of a given set of display modes.

6. The method according to claim 1 or 2, wherein the first output program language is executed and/or the second program language expressions are executed.

7. The method according to claim 1 or 2, further including processing, examination, execution, or any combination thereof, of the first program language and the second program language expressions so as to indicate en error or any lack of equivalence between the first program language and the second program language, and, if an error or an un- equivalence occurs, an error detection report is outputted.

8. The method according to any one of claims 1 to 4, further including validating that the mixed language program expressions are formulated correctly.

9. The method according to any one of claims 1 to 8, wherein the mixed- language program is generated from an input program encoded in the second program language.

10. The method according to any one of claims 1 to 8, wherein the mixed- language program is created directly in mixed-language code.

11. The method according to claim 9, further including validating that the second program output file (b) of claim 4, is functionally equivalent to said input program.

12. The method according to claim 11, wherein said validating includes: generating a second output program encoded in said second program language; feeding an input test vector to both the input program and to the second output program; and comparing an output test vector of the second output program to an output test vector of the input program.

13. The method according to claim 11, wherein said validating includes: generating second output program code encoded in said second program language; and comparing the code text of the second output program to the code text of the input program.

14. The method according to any one of the preceding claims , wherein the mixed- language program expressions represent a complete program.

15. The method according to any one of the preceding claims, wherein the mixed- language program expressions represent part of a program.

16. The method according to any one of the preceding claims, further including: generating and editing said mixed-language program expressions; and translating each mixed-language expression to first and second language expressions immediately after it is written and/or performing errors detection.

17. A system for generating a program in a first language compilable to run on a predetermined processor from a mixed-language program combining expressions of said first language and a second program language, the system comprising: a mixed language compiler for receiving mixed-language program expressions of a second program language and the first program language that allows generation of a first program language according to a set of pre-determined rules, and generates an executable output program encoded in said first language.

18. The system according to claim 17 wherein the mixed-language program comprises information, that allows the mixed-language compiler to convert the second program language to the first program language, according to the set of pre-determined rules.

19. The system according to claim 17 or 18, wherein: the first language is low-level; the mixed-language program expressions contain information relating to resources required by said predetermined processor in order to execute the expressions in the first language, and the system includes a compiler adapted to analyze the mixed language program expressions in order to extract said resources therefrom and produce the first program language, according to a set of pre determined rules.

20. The system according to any one of claims 17 to 19, wherein the system is adapted to validate that the mixed language program expressions are formulated correctly.

21. The system acςording to any one of claims 17 to 20, wherein the system is further adapted to generate the mixed language program from an input program encoded in the second program language.

22. The system according to claim 20, wherein the mixed language program expressions are derived from an input program encoded in the second program language and the system further comprises: a compiler for generating a second output program encoded in said second program language; and a comparator for comparing an output test vector of the second output program to an output test vector of the input program in response to an input test vector fed to both the input program and to the second output program.

23. The system according to claim 20, wherein the mixed language program expressions are derived from an input program encoded in the second program language and the system includes: a compiler for generating second output program code encoded in said second program language; and a comparator for comparing code of the second output program to code of the input program.

24. The system according to any one of claims 17 to 19, wherein the first language is low-level, and the first program language is presented in structured algebraic form.

25. The system according to any one of claims 17, 18 or 24, wherein the mixed- language compiler processes the mixed language program according to a set of predetermined rules and generates at least one of the following additional output files:

(a) first output program code encoded in said first program language; (b) second output program code encoded in said second program language;

(c) first output file encoded in the structured algebraic form;

(d) mixed language list file; and

(e) any combination of two or more of (a) to (d).

26. The system according to any one of claims 17 to 19, wherein the mixed- language compiler processes said mixed-language program so as to indicate an error or any lack of equivalence between the first program language and the second program language, and, if an error or an un-equivalence occurs, outputs an error detection report.

27. The system according to claim 17 or 18, wherein the processing of the first output program or the second output program by the mixed-language compiler

28. The system according to claims 26 or 27, wherein the compiler test or tests are performed by the mixed-language compiler on a complete mixed-language program file or any part of it.

29. The system according to any one of claims 17 to 19, further comprising a mixed-language simulator for processing and testing said mixed-language program.

30. The system according to claim 29, wherein the mixed-language simulator displays the mixed-language program in at least one of a given set of display modes.

31. The system according to claim 29 or 30, wherein the first language is low- level, and the mixed-language simulator displays the first program language in structured algebraic form.

32. The system according to any one of claims 29 to 31 , wherein the mixed- language simulator is adapted to execute the first program language and/or the second program language.

33. The system according to claim 32, wherein the mixed-language simulator is further adapted to perform an error tests and/or equivalency check between the first program language expressions and the program encoded in the second language, and to output an error detection report if an error or an un-equivalency occurs.

34. The system according to any one of claims 28 to 33, wherein the mixed- language simulator is adapted to process and test of the first program language and/or the second program language.

35. The system according to claim 34, wherein the test or tests are performed by the mixed-language simulator on a complete output program file or any part of it.

36. The system according to any one of claims 17 to 19, further comprising a mixed-language emulator for processing and testing said mixed-language program.

37. The system according to claim 36, wherein the mixed-language emulator displays the mixed program in at least one of a given set of display modes.

38. The system according to claim 36 to 37, wherein the first language is low-level and the mixed-language emulator displays the first program language in structured algebraic form.

39. The system according to any one of claims 36 to 38, wherein the mixed- language emulator is adapted to execute the first program language and/or the second program language.

40. The system according to claim 39, wherein the mixed-language emulator is further adapted to perform an error test and/or equivalency check between the first program language and the second program language, and to output an error detection report if an error or an un-equivalency occurs.

41. The system according to any one of claim 36 or 40, wherein the mixed- language emulator is adapted to process and test of the first program language and/or the second program language.

42. The system according to claim 4 , wherein the test or tests are run by the mixed-language emulator on a complete output program file or any part of it.

43. The system according to any one of claims 17 or 19, further including an editor adapted to generate the mixed-language program through translation of each mixed- language expression immediately after it is written.

44. The system according to claim 17 or 19 further including an mixed -language editor , wherein the mixed-language editor is further adapted to perform errors detection in the mixed-language expressions entered thereto.