# A very special feature

cpik works in a unusual way: unlike other compilers, it does not produce ordinary assembler code but source libraries.

A source library looks like a PIC 18 asm source file, with `.slb` extension. This file can be processed by an assembler (such as `mpasm` or `gpasm`) but contains special comments that are intended to be used as directives by the linker. This linker is included in cpik itself, so the `cpik` command can be used for both compilation and link tasks.

The important point is that cpik linker works at assembly source code level: it picks needed "modules" from source libraries and copies them in a single output file. In other words, `cpik` performs linking before assembly stage (In contrast, most linkers work from the object code generated by an assembler).

The file generated by the linker is easy to verify manually, and I suppose (and hope) that advanced users will examine it and will send feedbacks about the code.

This unusual approach presents for me several advantages:

- Any source library is a simple text file, so it can be manually written in assembly language, using a standard text editor (this point is important to bootstrap a totally new development environment). For example, the LCD library has been developped from scratch with a text editor as unique tool, and has been used to support the very first program3compiled with cpik ever executed (see figure 1).

- source libraries do not depend on any object/library format, and/or obscure, potentially undocumented and volatile format versions.

- the final executable code (ie: hex file) can be generated by a very simple assembler without any advanced feature (The target assembler is currently `gpasm` running in absolute mode - ie: without program sections).

- any output from the compiler is potentially a library, so there is no more differences between object files and libraries. As a consequence, we do not need any librarian utility.

- the linking process is globally very simple and does not increase significantly the complexity/size of `cpik` executable.

- this design has proven its flexibility for the implementation of support for data located in ROM, or jumps optimisations

- symbolic calculations that depend on the location of entities in memory can be deferred to assembly stage.

In fact, the «source library» approach might be rather slow, but, as microcontrollers applications are not huge, your computer will build ready-to-burn hex files at speed of light.

Figure: Result of the very first program compiled by `cpik` ever executed

#### Footnotes

... program 3
  Believe it or not, this program (a simple `for` loop) worked successfully at the first execution. To be honest, this execution has been preceded by many manual check of the generated code.