ACE CoSy Compiler Design Cycle

Step 1:

SZCHAR = 8

          SZSHORT = 16

          SZINT = 32

          SZLONG = 32

          SZLONG2 = 64

          SZFLOAT = 32

          SZDOUBLE = 64

          SZQUAD = 64

          SZPOINT = 32

          

          SPACE = "__X" {

              METHOD = 1

              ALPOINT = 32 # true definition

              SZPOINT = 32 # of pointer shape

              

              CIRCALPOINT = 32 # definition of

              CIRCSZPOINT = 96 # circular pointer

          }

As the first step in the construction of a CoSy compiler, the target description file (TDF) is created. The TDF specifies detailed information on the target architecture's data model, the sizes of the C data types, endianness, bit-width, alignments and available memory spaces, all of which can be specified in arbitrary sizes. The target description information is used for general storage allocation and constant expression evaluation throughout the entire compiler, as well as to parameterize CoSy analysis and optimization engines.

Step 2:

REGISTER (* The registers to be used *)

              r0,r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,sp,lr,pc;

          

          REGISTER SET

              (* registers changed by a function call *)

              funcall_changes: r0,r1,r2,r3,r12,lr;

              funcall_saved: r4..r11;

          

          REGISTER AVAIL <r0..r12, lr>;

              (* The registers available to the allocator *)

CoSy compiler back-end components, such as the matcher, scheduler, register allocator and emitter, are generated based upon the information that is provided in Code Generator Description files (CGD). The relationship between the CoSy IR and sequences of target instructions is defined through a hierarchical system of rules. As a trivial starter in the CGD, the register file and characteristics of available registers are described.

Step 3:


          NONTERMINAL

              reg REGISTER <r0..pc>,

              shop ADDRMODE (shop: shop_t);

          

          RULE [add] o:mirPlus (Rn:reg, s:shop) -> Rd:reg;

          CONDITION { IS_INT32(o.Type) };

          COST 1;

          EMIT {

              /* ADD Rd,Rn,<shop> */

              fprintf

              (  OUTFILE

              ,  "\tADD %s,%s,"

              ,  REGNAME(Rd), REGNAME(Rn)

              );

              fprint_shop(OUTFILE, s.shop);

              fputc('\n', OUTFILE);

          }

          END

          

          END

A more elaborate task within the CGD is to map the CoSy intermediate representation (IR) to the instructions that are available in the architecture's instruction set. This mapping by so-called RULES basically encompasses the core of the code generator. Starting from the available prototype code generator and guided by CoSy's built-in incremental code generator test environment Compiler Trainer, this is a straightforward job. As the development of the compiler progresses, increasingly stringent Compiler Trainer tests guide the compiler engineer along the best-practice path towards a stable and robust compiler.

Step 4:

ENGINE CLASS lower(IN u: mirUnit; IN t: TarDes)

          {

              REGION p{} : mirProcGlobal;

          

          PIPELINE

              unit2proc (u, p{})

              lowercom (p, u, t)

              lowerpfc (p, u, t)

              lowerboolval (p, u, t)

              lowerbitfield (p, u, t)

              setpsr (p, u, t)

              allocpr (p, u, t)

          }

Each CoSy compiler consists of a supervisor, which implements control and data flow through the compiler and protects the IR against access conflicts. The supervisor calls CoSy engines to execute in a hierarchy of interactions and can be made specific to the target architecture/application domain. The EDL supervisor configuration file defines which CoSy engines should be incorporated in the compiler and their specific configuration regarding e.g. stack frame layout, spill frames and parameter passing conventions.

Step 5:


          SCHEDULER

              PRODUCER  DEFPROD, LOADPROD;

              CONSUMER  DEFCONS;

          

              TRUE DEFCONS :

              DEFPROD 1,

              LOADPROD 3;

          

              OUTPUT DEFPROD :

              LOADPROD 2;

          

              RESOURCES

                  unit0, unit1, unit2, ldst0, ldst1;

              TEMPLATES

                  DEFTMPL := unit0 + unit1 + unit2 + ldst0 + ldst1;

                  ALUTMPL := unit0 | unit1;

                  MULTMPL := 3 * unit0;

                  DIVTMPL := 5 * unit0;

                  SHIFTTMPL := unit1 | unit2;

                  MOVETMPL := unit0 | unit1 | unit2;

                  FLOATTMPL := unit2;

                  LDSTTMPL := ldst0 | ldst1;

With the focus on creating an optimizing compiler that takes full benefit of the architecture's features, instruction scheduling is the first optimization that could be taken up. The CGD is augmented with a SCHEDULER section that contains two sets of descriptions. One description set focuses on latencies, specifying the number of cycles it takes for the result of an instruction to become available for another instruction. The other set describes resource use, specifying the cycles in which the architecture's functional units, or any other resource like data paths, are occupied by an instruction. Furthermore, the rules that exhibit non-default latencies or resource use are annotated with the defined latency classes and resource use patterns.

Next steps:
After creation of the initial, validating compiler, the next step is to add specific features, such as Dwarf 2 debug information support, inline assembly, compiler known functions, alternative calling conventions, special pragma support, as well as further optimization of the compiler for best performance. Depending on the requirements of the compiler, additional effort in obtaining the desired performance may be necessary. This is where CoSy users once again experience the ease of enhancing a CoSy compiler by adding specific analysis and optimization engines. CoSy's robust, extensible framework enables compiler engineers to focus at the main objective: a high quality, high performance compiler.

Contact ACE:
If you are interested in more details about the steps towards a high quality/ high performance compiler for your particular processor architecture, then do not hesitate to contact us or fill out the web-request form.

CoSy Design Cycle

Experience developing compilers with CoSy!