# System unit

In FPC the system unit is the unit that is included by every program. FPC's run-time library comes with a system unit where most, if not all of its functionalities work on every available platform.

## compilation of system units

To compile a system unit one calls FPC with the -Us flag. This will tell the compiler that only basic type definitions are being made, and including a system unit is skipped. Types such as integer won't be available.

### mandatory tasks of system unit

If you attempt to create your own system unit, you'll incrementally notice what the compiler needs or what the generated code expects. On a Linux target, the minimal system unit has to contain:

1. unit system;
2. 
3. interface

The type definition of hresult.

1. type
2. 	hresult = longint;

The identifier operatingsystem_result has to be declared. The data stored at that position are communicated to the operating system as return value. Whether hresult and operatingsystem_result are defined in the interface section is irrelevant. However, it is very plausible to put those into the interface section, so programs using this system unit can manipulate those.

1. var
2. 	exitCode: hresult = 0; export name 'operatingsystem_result';
3. 
4. implementation

Here comes to light what the system responsibilities are: It has to initialize (or should) initialize units, that means call every unit's initialization routines. For that the label FPC_INITIALIZEUNITS has to be defined.

1. procedure initializeUnits; alias: 'FPC_INITIALIZEUNITS';
2. begin
3. end;

Also the label FPC_DO_EXIT has to be defined. Here, system unit programmers have the chance to finalize units.

1. procedure doExit; alias: 'FPC_DO_EXIT';
2. begin
3. end;
4. 
5. end.

Furthermore FPC will possibly complain the unit fpintres.pp were missing. So create a file fpintres.pas:

1. unit FPIntRes;
2. interface
3. implementation
4. end.

After doing so, you can compile your system unit with fpc -Us system.pas, or directly create an empty program and compile it to examine the impact on the binary's size. On a x86-64 Linux target the executable had a size of 2744 bytes. The big trade-off is no convenience. All functionality that can't be “implemented” by the compiler is gone. For example addr or ord still work, while sin or random are not available.

Note: Depending on what your program uses, there might other mandatory tasks, too. Especially OOP won't work without a functional objpas unit.

### initialization and finalization of units

For those who are curious, how to implement FPC_INITIALIZEUNITS: FPC puts into every program's data section a INITFINAL table. Compiling a program with the -al flag will retain the assembler file. Examining it you will encounter something like:

1. .section .data.n_INITFINAL
2.         .balign 8
3. .globl  INITFINAL
4.         .type   INITFINAL,@object
5. INITFINAL:
6.         .quad   1,0
7.         .quad   INIT$_$SOMEUNIT
8.         .quad   FINALIZE$_$SOMEUNIT

For further investigations have a glimpse at an actual implementation helps: rtl/inc/system.inc.

Note: In general, implementing an “own” system unit is a stupid idea. There is “smartlinking” if size matters.

## comparative remarks

Other compilers such as GPC or Delphi use similar constructs, but to varying extent, and the system unit is not necessarily named system.pp.