SDCC Compiler User Guide

SDCC Compiler User Guide

Chapter 3

Using SDCC

3.1

Compiling

3.1.1

Single Source File Projects

For single source file 8051 projects the process is very simple. Compile your programs with the following command

"sdcc sourcefile.c".

This will compile, assemble and link your source file. Output files are as follows:

• sourcefile.asm - Assembler source file created by the compiler

• sourcefile.lst - Assembler listing file created by the Assembler

• sourcefile.rst - Assembler listing file updated with linkedit information, created by linkage editor

• sourcefile.sym - symbol listing for the sourcefile, created by the assembler

• sourcefile.rel or sourcefile.o - Object file created by the assembler, input to Linkage editor

• sourcefile.map - The memory map for the load module, created by the Linker

• sourcefile.mem - A file with a summary of the memory usage

• sourcefile.ihx - The load module in Intel hex format (you can select the Motorola S19 format with --out-fmts19. If you need another format you might want to use

objdump

or

srecord

). Both formats are documented in the documentation of srecord

• sourcefile.adb - An intermediate file containing debug information needed to create the .cdb file (with -debug)

• sourcefile.cdb - An optional file (with --debug) containing debug information. The format is documented in cdbfileformat.pdf

• sourcefile. - (no extension) An optional AOMF or AOMF51 file containing debug information (generated with option --debug). The (Intel) absolute object module f ormat is commonly used by third party tools

(debuggers, simulators, emulators)

• sourcefile.dump* - Dump file to debug the compiler it self (generated with option --dumpall) (see section

3.2.9

and section

9.1

”Anatomy of the compiler”).

3.1.2

Projects with Multiple Source Files

SDCC can compile only ONE file at a time. Let us for example assume that you have a project containing the following files: foo1.c (contains some functions) foo2.c (contains some more functions) foomain.c (contains more functions and the function main)

19

3.1. COMPILING CHAPTER 3. USING SDCC

The first two files will need to be compiled separately with the commands:

sdcc -c foo1.c

sdcc -c foo2.c

Then compile the source file containing the main() function and link the files together with the following command:

sdcc foomain.c foo1.rel foo2.rel

Alternatively, foomain.c can be separately compiled as well:

sdcc -c foomain.c

sdcc foomain.rel foo1.rel foo2.rel

The file containing the main() function

MUST be the

FIRST file specified in the command line, since the linkage editor processes file in the order they are presented to it. The linker is invoked from SDCC using a script file with extension .lnk. You can view this file to troubleshoot linking problems such as those arising from missing libraries.

3.1.3

Projects with Additional Libraries

Some reusable routines may be compiled into a library, see the documentation for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc) for how to create a .lib library file. Libraries created in this manner can be included in the command line. Make sure you include the -L <library-path> option to tell the linker where to look for these files if they are not in the current directory. Here is an example, assuming you have the source file foomain.c and a library foolib.lib in the directory mylib (if that is not the same as your current project):

sdcc foomain.c foolib.lib -L mylib

Note here that mylib must be an absolute path name.

The most efficient way to use libraries is to keep separate modules in separate source files.

The lib file now should name all the modules.rel files. For an example see the standard library file libsdcc.lib in the directory

<installdir>/share/lib/small.

3.1.4

Using sdcclib to Create and Manage Libraries

Alternatively, instead of having a .rel file for each entry on the library file as described in the preceding section, sdcclib can be used to embed all the modules belonging to such library in the library file itself. This results in a larger library file, but it greatly reduces the number of disk files accessed by the linker. Additionally, the packed library file contains an index of all include modules and symbols that significantly speeds up the linking process.

To display a list of options supported by sdcclib type:

sdcclib -?

To create a new library file, start by compiling all the required modules. For example:

sdcc -c _divsint.c

sdcc -c _divuint.c

sdcc -c _modsint.c

sdcc -c _moduint.c

sdcc -c _mulint.c

This will create files _divsint.rel, _divuint.rel, _modsint.rel, _moduint.rel, and _mulint.rel. The next step is to add the .rel files to the library file:

20

3.2. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC

sdcclib libint.lib _divsint.rel

sdcclib libint.lib _divuint.rel

sdcclib libint.lib _modsint.rel

sdcclib libint.lib _moduint.rel

sdcclib libint.lib _mulint.rel

If the file already exists in the library, it will be replaced. To see what modules and symbols are included in the library, options -s and -m are available. For example:

sdcclib -s libint.lib

_divsint.rel:

__divsint_a_1_1

__divsint_PARM_2

__divsint

_divuint.rel:

__divuint_a_1_1

__divuint_PARM_2

__divuint_reste_1_1

__divuint_count_1_1

__divuint

_modsint.rel:

__modsint_a_1_1

__modsint_PARM_2

__modsint

_moduint.rel:

__moduint_a_1_1

__moduint_PARM_2

__moduint_count_1_1

__moduint

_mulint.rel:

__mulint_PARM_2

__mulint

If the source files are compiled using --debug, the corresponding debug information file .adb will be include in the library file as well. The library files created with sdcclib are plain text files, so they can be viewed with a text editor. It is not recomended to modify a library file created with sdcclib using a text editor, as there are file indexes numbers located accross the file used by the linker to quickly locate the required module to link. Once a .rel file

(as well as a .adb file) is added to a library using sdcclib, it can be safely deleted, since all the information required for linking is embedded in the library file itself. Library files created using sdcclib are used as described in the preceding sections.

3.2

Command Line Options

3.2.1

Processor Selection Options

-mmcs51

Generate code for the Intel MCS51 family of processors. This is the default processor target.

-mds390

Generate code for the Dallas DS80C390 processor.

-mds400

Generate code for the Dallas DS80C400 processor.

-mhc08

Generate code for the Freescale/Motorola HC08 family of processors.

-mz80

Generate code for the Zilog Z80 family of processors.

-mgbz80

Generate code for the GameBoy Z80 processor (Not actively maintained).

21

3.2. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC

-mavr

Generate code for the Atmel AVR processor (In development, not complete). AVR users should probably have a look at winavr http://sourceforge.net/projects/winavr or http://www.

avrfreaks.net/index.php?name=PNphpBB2&file=index

.

-mpic14

Generate code for the Microchip PIC 14-bit processors (p16f84 and variants. In development, not complete).

-mpic16

Generate code for the Microchip PIC 16-bit processors (p18f452 and variants. In development, not complete).

-mtlcs900h Generate code for the Toshiba TLCS-900H processor (Not maintained, not complete).

-mxa51

Generate code for the Phillips XA51 processor (Not maintained, not complete).

3.2.2

Preprocessor Options

-I<path>

The additional location where the pre processor will look for <..h> or “..h” files.

-D<macro[=value]> Command line definition of macros. Passed to the preprocessor.

-M

Tell the preprocessor to output a rule suitable for make describing the dependencies of each object file.

For each source file, the preprocessor outputs one make-rule whose target is the object file name for that source file and whose dependencies are all the files ‘#include’d in it. This rule may be a single line or may be continued with ‘\’-newline if it is long. The list of rules is printed on standard output instead of the preprocessed C program. ‘-M’ implies ‘-E’.

-C

-MM

Tell the preprocessor not to discard comments. Used with the ‘-E’ option.

Like ‘-M’ but the output mentions only the user header files included with ‘#include “file"’. System header files included with ‘#include <file>’ are omitted.

-Aquestion(answer) Assert the answer answer for question, in case it is tested with a preprocessor conditional such as ‘#if #question(answer)’. ‘-A-’ disables the standard assertions that normally describe the target machine.

-Umacro

Undefine macro macro. ‘-U’ options are evaluated after all ‘-D’ options, but before any ‘-include’ and

‘-imacros’ options.

-dM

Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of preprocessing. Used with the ‘-E’ option.

-dD

-dN

Tell the preprocessor to pass all macro definitions into the output, in their proper sequence in the rest of the output.

Like ‘-dD’ except that the macro arguments and contents are omitted. Only ‘#define name’ is included in the output.

-Wp preprocessorOption[,preprocessorOption]... Pass the preprocessorOption to the preprocessor sdcpp

.

SDCC uses an adapted version of the preprocessor cpp of the GNU Compiler

Collection (gcc), if you need more dedicated options please refer to the documentation at http://www.gnu.org/software/gcc/onlinedocs/

.

3.2.3

Linker Options

-L --lib-path <absolute path to additional libraries> This option is passed to the linkage editor’s additional libraries search path. The path name must be absolute. Additional library files may be specified in the command line. See section Compiling programs for more details.

--xram-loc <Value> The start location of the external ram, default value is 0. The value entered can be in Hexadecimal or Decimal format, e.g.: --xram-loc 0x8000 or --xram-loc 32768.

22

3.2. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC

--code-loc <Value> The start location of the code segment, default value 0. Note when this option is used the interrupt vector table is also relocated to the given address. The value entered can be in Hexadecimal or Decimal format, e.g.: --code-loc 0x8000 or --code-loc 32768.

--stack-loc <Value> By default the stack is placed after the data segment. Using this option the stack can be placed anywhere in the internal memory space of the 8051. The value entered can be in Hexadecimal or Decimal format, e.g. --stack-loc 0x20 or --stack-loc 32. Since the sp register is incremented before a push or call, the initial sp will be set to one byte prior the provided value. The provided value should not overlap any other memory areas such as used register banks or the data segment and with enough space for the current application. The --pack-iram option (which is now a default setting) will override this setting, so you should also specify the --no-pack-iram option if you need to manually place the stack.

--data-loc <Value> The start location of the internal ram data segment. The value entered can be in Hexadecimal or Decimal format, eg. --data-loc 0x20 or --data-loc 32. (By default, the start location of the internal ram data segment is set as low as possible in memory, taking into account the used register banks and the bit segment at address 0x20. For example if register banks 0 and 1 are used without bit variables, the data segment will be set, if --data-loc is not used, to location 0x10.)

--idata-loc <Value> The start location of the indirectly addressable internal ram of the 8051, default value is 0x80.

The value entered can be in Hexadecimal or Decimal format, eg. --idata-loc 0x88 or --idata-loc 136.

--bit-loc <Value> The start location of the bit addressable internal ram of the 8051. This is not implemented yet.

Instead an option can be passed directly to the linker: -Wl -bBSEG=<Value>.

--out-fmt-ihx The linker output (final object code) is in Intel Hex format. This is the default option. The format itself is documented in the documentation of srecord.

--out-fmt-s19 The linker output (final object code) is in Motorola S19 format. The format itself is documented in the documentation of srecord.

--out-fmt-elf The linker output (final object code) is in ELF format. (Currently only supported for the HC08 processors)

-Wl linkOption[,linkOption]... Pass the linkOption to the linker. See file sdcc/as/doc/asxhtm.html for more on linker options.

3.2.4

MCS51 Options

--model-small Generate code for Small Model programs, see section Memory Models for more details. This is the default model.

--model-medium Generate code for Medium model programs, see section Memory Models for more details. If this option is used all source files in the project have to be compiled with this option. It must also be used when invoking the linker.

--model-large Generate code for Large model programs, see section Memory Models for more details. If this option is used all source files in the project have to be compiled with this option. It must also be used when invoking the linker.

--xstack

Uses a pseudo stack in the first 256 bytes in the external ram for allocating variables and passing parameters. See section

3.17.1.2

External Stack for more details.

--iram-size <Value> Causes the linker to check if the internal ram usage is within limits of the given value.

--xram-size <Value> Causes the linker to check if the external ram usage is within limits of the given value.

--code-size <Value> Causes the linker to check if the code memory usage is within limits of the given value.

--stack-size <Value> Causes the linker to check if there is at minimum <Value> bytes for stack.

--pack-iram Causes the linker to use unused register banks for data variables and pack data, idata and stack together. This is the default now.

--no-pack-iram Causes the linker to use old style for allocating memory areas.

23

3.2. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC

3.2.5

DS390 / DS400 Options

--model-flat24 Generate 24-bit flat mode code. This is the one and only that the ds390 code generator supports right now and is default when using -mds390. See section Memory Models for more details.

--protect-sp-update disable interrupts during ESP:SP updates.

--stack-10bit Generate code for the 10 bit stack mode of the Dallas DS80C390 part. This is the one and only that the ds390 code generator supports right now and is default when using -mds390. In this mode, the stack is located in the lower 1K of the internal RAM, which is mapped to 0x400000. Note that the support is incomplete, since it still uses a single byte as the stack pointer. This means that only the lower 256 bytes of the potential 1K stack space will actually be used. However, this does allow you to reclaim the precious 256 bytes of low RAM for use for the DATA and IDATA segments. The compiler will not generate any code to put the processor into 10 bit stack mode. It is important to ensure that the processor is in this mode before calling any re-entrant functions compiled with this option. In principle, this should work with the --stack-auto option, but that has not been tested. It is incompatible with the --xstack option. It also only makes sense if the processor is in 24 bit contiguous addressing mode (see the --model-flat24 option).

--stack-probe insert call to function __stack_probe at each function prologue.

--tini-libid <nnnn> LibraryID used in -mTININative.

--use-accelerator generate code for DS390 Arithmetic Accelerator.

3.2.6

Z80 Options

--callee-saves-bc Force a called function to always save BC.

--no-std-crt0 When linking, skip the standard crt0.o object file. You must provide your own crt0.o for your system when linking.

3.2.7

Optimization Options

--nogcse

Will not do global subexpression elimination, this option may be used when the compiler creates undesirably large stack/data spaces to store compiler temporaries (spill locations, sloc). A warning message will be generated when this happens and the compiler will indicate the number of extra bytes it allocated. It is recommended that this option NOT be used, #pragma nogcse can be used to turn off global subexpression elimination for a given function only.

--noinvariant Will not do loop invariant optimizations, this may be turned off for reasons explained for the previous option. For more details of loop optimizations performed see Loop Invariants in section

8.1.4

. It

is recommended that this option NOT be used, #pragma noinvariant can be used to turn off invariant optimizations for a given function only.

--noinduction Will not do loop induction optimizations, see section strength reduction for more details. It is recommended that this option is NOT used, #pragma noinduction can be used to turn off induction optimizations for a given function only.

--nojtbound Will not generate boundary condition check when switch statements are implemented using jumptables. See section

8.1.7

Switch Statements for more details. It is recommended that this option is

NOT used, #pragma nojtbound can be used to turn off boundary checking for jump tables for a given function only.

--noloopreverse Will not do loop reversal optimization.

--nolabelopt Will not optimize labels (makes the dumpfiles more readable).

--no-xinit-opt Will not memcpy initialized data from code space into xdata space. This saves a few bytes in code space if you don’t have initialized data.

24

3.2. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC

--nooverlay The compiler will not overlay parameters and local variables of any function, see section Parameters and local variables for more details.

--no-peep

Disable peep-hole optimization.

--peep-file <filename> This option can be used to use additional rules to be used by the peep hole optimizer. See section

8.1.13

Peep Hole optimizations for details on how to write these rules.

--peep-asm Pass the inline assembler code through the peep hole optimizer. This can cause unexpected changes to inline assembler code, please go through the peephole optimizer rules defined in the source file tree

’<target>/peeph.def’ before using this option.

--opt-code-speed The compiler will optimize code generation towards fast code, possibly at the expense of code size.

--opt-code-size The compiler will optimize code generation towards compact code, possibly at the expense of code speed.

3.2.8

Other Options

-c --compile-only will compile and assemble the source, but will not call the linkage editor.

--c1mode

reads the preprocessed source from standard input and compiles it. The file name for the assembler output must be specified using the -o option.

-E

Run only the C preprocessor. Preprocess all the C source files specified and output the results to standard output.

-o <path/file> The output path resp. file where everything will be placed. If the parameter is a path, it must have a trailing slash (or backslash for the Windows binaries) to be recognized as a path.

--stack-auto All functions in the source file will be compiled as reentrant, i.e. the parameters and local variables will be allocated on the stack. See section

3.6

Parameters and Local Variables for more details. If this option is used all source files in the project should be compiled with this option. It automatically implies –int-long-reent and –float-reent.

--callee-saves function1[,function2][,function3].... The compiler by default uses a caller saves convention for register saving across function calls, however this can cause unnecessary register pushing & popping when calling small functions from larger functions. This option can be used to switch the register saving convention for the function names specified. The compiler will not save registers when calling these functions, no extra code will be generated at the entry & exit (function prologue & epilogue) for these functions to save & restore the registers used by these functions, this can SUBSTANTIALLY reduce code & improve run time performance of the generated code. In the future the compiler (with inter procedural analysis) will be able to determine the appropriate scheme to use for each function call. DO NOT use this option for built-in functions such as _mulint..., if this option is used for a library function the appropriate library function needs to be recompiled with the same option. If the project consists of multiple source files then all the source file should be compiled with the same --callee-saves option string. Also see #pragma callee_saves.

--debug

When this option is used the compiler will generate debug information. The debug information collected in a file with .cdb extension can be used with the SDCDB. For more information see documentation for SDCDB. Another file with no extension contains debug information in AOMF or AOMF51 format which is commonly used by third party tools.

-S

Stop after the stage of compilation proper; do not assemble. The output is an assembler code file for the input file specified.

--int-long-reent Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant. Note by default these libraries are compiled as non-reentrant. See section Installation for more details.

25

3.2. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC

--cyclomatic This option will cause the compiler to generate an information message for each function in the source file. The message contains some important information about the function. The number of edges and nodes the compiler detected in the control flow graph of the function, and most importantly the cyclomatic complexity see section on Cyclomatic Complexity for more details.

--float-reent Floating point library is compiled as reentrant. See section Installation for more details.

--main-return This option can be used if the code generated is called by a monitor program or if the main routine includes an endless loop. This option might result in slightly smaller code and save two bytes of stack space. The return from the ’main’ function will return to the function calling main. The default setting is to lock up i.e. generate a ’sjmp .’.

--nostdinc This will prevent the compiler from passing on the default include path to the preprocessor.

--nostdlib This will prevent the compiler from passing on the default library path to the linker.

--verbose

Shows the various actions the compiler is performing.

-V

Shows the actual commands the compiler is executing.

--no-c-code-in-asm Hides your ugly and inefficient c-code from the asm file, so you can always blame the compiler

:)

--no-peep-comments Will not include peep-hole comments in the generated files.

--i-code-in-asm Include i-codes in the asm file. Sounds like noise but is most helpful for debugging the compiler itself.

--less-pedantic Disable some of the more pedantic warnings (jwk burps: please be more specific here, please!).

--disable-warning <nnnn> Disable specific warning with number <nnnn>.

--print-search-dirs Display the directories in the compiler’s search path

--vc

Display errors and warnings using MSVC style, so you can use SDCC with visual studio.

--use-stdout Send errors and warnings to stdout instead of stderr.

-Wa asmOption[,asmOption]... Pass the asmOption to the assembler. See file sdcc/as/doc/asxhtm.html for assembler options.cd

--std-sdcc89 Generally follow the C89 standard, but allow SDCC features that conflict with the standard (default).

--std-c89

Follow the C89 standard and disable SDCC features that conflict with the standard.

--std-sdcc99 Generally follow the C99 standard, but allow SDCC features that conflict with the standard (incomplete support).

--std-c99

Follow the C99 standard and disable SDCC features that conflict with the standard (incomplete support).

--codeseg <Name> The name to be used for the code segment, default CSEG. This is useful if you need to tell the compiler to put the code in a special segment so you can later on tell the linker to put this segment in a special place in memory. Can be used for instance when using bank switching to put the code in a bank.

--constseg <Name> The name to be used for the const segment, default CONST. This is useful if you need to tell the compiler to put the const data in a special segment so you can later on tell the linker to put this segment in a special place in memory. Can be used for instance when using bank switching to put the const data in a bank.

26

3.3. ENVIRONMENT VARIABLES CHAPTER 3. USING SDCC

more-pedantic Actually this is not a SDCC compiler option but if you want more warnings you can use a separate tool dedicated to syntax checking like splint http://www.splint.org

. To make your source files parseable by splint you will have to include lint.h

in your source file and add brackets around extended keywords (like ”__at (0xab)” and ”__interrupt (2)” ).

Splint has an excellent on line manual at http://www.splint.org/manual/ and it’s capabilities go beyond pure syntax checking. You’ll need to tell splint the location of SDCC’s include files so a typical command line could look like this: splint -I /usr/local/share/sdcc/include/mcs51/ myprogram.c

3.2.9

Intermediate Dump Options

The following options are provided for the purpose of retargetting and debugging the compiler. They provide a means to dump the intermediate code (iCode) generated by the compiler in human readable form at various stages of the compilation process. More on iCodes see chapter

9.1

”The anatomy of the compiler”.

--dumpraw This option will cause the compiler to dump the intermediate code into a file of named <source

filename>.dumpraw just after the intermediate code has been generated for a function, i.e. before any optimizations are done. The basic blocks at this stage ordered in the depth first number, so they may not be in sequence of execution.

--dumpgcse Will create a dump of iCode’s, after global subexpression elimination, into a file named <source

filename>.dumpgcse.

--dumpdeadcode Will create a dump of iCode’s, after deadcode elimination, into a file named <source file-

name>.dumpdeadcode.

--dumploop Will create a dump of iCode’s, after loop optimizations, into a file named <source file-

name>.dumploop.

--dumprange Will create a dump of iCode’s, after live range analysis, into a file named <source file-

name>.dumprange.

--dumlrange Will dump the life ranges for all symbols.

--dumpregassign Will create a dump of iCode’s, after register assignment, into a file named <source file-

name>.dumprassgn.

--dumplrange Will create a dump of the live ranges of iTemp’s

--dumpall Will cause all the above mentioned dumps to be created.

3.2.10

Redirecting output on Windows Shells

By default SDCC writes it’s error messages to ”standard error”.

To force all messages to ”standard output” use --use-stdout. Additionally, if you happen to have visual studio installed in your windows machine, you can use it to compile your sources using a custom build and the SDCC --vc option. Something like this should work:

c:\sdcc\bin\sdcc.exe --vc --model-large -c $(InputPath)

3.3

Environment variables

SDCC recognizes the following environment variables:

SDCC_LEAVE_SIGNALS SDCC installs a signal handler to be able to delete temporary files after an user break

(^C) or an exception. If this environment variable is set, SDCC won’t install the signal handler in order to be able to debug SDCC.

TMP, TEMP, TMPDIR Path, where temporary files will be created. The order of the variables is the search order.

In a standard *nix environment these variables are not set, and there’s no need to set them. On Windows it’s recommended to set one of them.

27

3.4. STORAGE CLASS LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC

SDCC_HOME Path, see section

2.2

” Install Paths”.

SDCC_INCLUDE Path, see section

2.3

”Search Paths”.

SDCC_LIB Path, see section

2.3

”Search Paths”..

There are some more environment variables recognized by SDCC, but these are solely used for debugging purposes.

They can change or disappear very quickly, and will never be documented.

3.4

Storage Class Language Extensions

3.4.1

MCS51/DS390 Storage Class Language Extensions

In addition to the ANSI storage classes SDCC allows the following MCS51 specific storage classes:

3.4.1.1

data / near

This is the default storage class for the Small Memory model (data and near can be used synonymously). Variables declared with this storage class will be allocated in the directly addressable portion of the internal RAM of a 8051, e.g.: data unsigned char test_data;

Writing 0x01 to this variable generates the assembly code:

75*00 01 mov _test_data,#0x01

3.4.1.2

xdata / far

Variables declared with this storage class will be placed in the external RAM. This is the default storage class for the Large Memory model, e.g.: xdata unsigned char test_xdata;

Writing 0x01 to this variable generates the assembly code:

90s00r00 mov dptr,#_test_xdata

74 01 mov a,#0x01

F0 movx @dptr,a

3.4.1.3

idata

Variables declared with this storage class will be allocated into the indirectly addressable portion of the internal ram of a 8051, e.g.: idata unsigned char test_idata;

Writing 0x01 to this variable generates the assembly code:

78r00

76 01 mov mov r0,#_test_idata

@r0,#0x01

Please note, the first 128 byte of idata physically access the same RAM as the data memory. The original 8051 had

128 byte idata memory, nowadays most devices have 256 byte idata memory. The stack is located in idata memory.

28

3.4. STORAGE CLASS LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC

3.4.1.4

pdata

Paged xdata access is just as straightforward as using the other addressing modes of a 8051. It is typically located at the start of xdata and has a maximum size of 256 bytes. The following example writes 0x01 to the pdata variable.

Please note, pdata access physically accesses xdata memory. The high byte of the address is determined by port

P2 (or in case of some 8051 variants by a separate Special Function Register, see section

4.1

). This is the default

storage class for the Medium Memory model, e.g.: pdata unsigned char test_pdata;

Writing 0x01 to this variable generates the assembly code:

78r00

74 01

F2 mov r0,#_test_pdata mov a,#0x01 movx @r0,a

If the --xstack option is used the pdata memory area is followed by the xstack memory area and the sum of their sizes is limited to 256 bytes.

3.4.1.5

code

’Variables’ declared with this storage class will be placed in the code memory: code unsigned char test_code;

Read access to this variable generates the assembly code:

90s00r6F mov dptr,#_test_code

E4 clr a

93 movc a,@a+dptr char indexed arrays of characters in code memory can be accessed efficiently: code char test_array[] = {’c’,’h’,’e’,’a’,’p’};

Read access to this array using an 8-bit unsigned index generates the assembly code:

E5*00 mov a,_index

90s00r41 mov dptr,#_test_array

93 movc a,@a+dptr

3.4.1.6

bit

This is a data-type and a storage class specifier. When a variable is declared as a bit, it is allocated into the bit addressable memory of 8051, e.g.: bit test_bit;

Writing 1 to this variable generates the assembly code:

D2*00 setb _test_bit

The bit addressable memory consists of 128 bits which are located from 0x20 to 0x2f in data memory.

Apart from this 8051 specific storage class most architectures support ANSI-C bitfields

1

. In accordance with

ISO/IEC 9899 bits and bitfields without an explicit signed modifier are implemented as unsigned.

1

Not really meant as examples, but nevertheless showing what bitfields are about: device/include/mc68hc908qy.h and support/regression/tests/bitfields.c

29

3.4. STORAGE CLASS LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC

3.4.1.7

sfr / sfr16 / sfr32 / sbit

Like the bit keyword, sfr / sfr16 / sfr32 / sbit signify both a data-type and storage class, they are used to describe the special f unction registers and special bit variables of a 8051, eg: sfr at 0x80 P0; /* special function register P0 at location 0x80 */

/* 16 bit special function register combination for timer 0 */

/* with the high byte at location 0x8C and the low byte at location 0x8A */ sfr16 at 0x8C8A TMR0; sbit at 0xd7 CY; /* CY (Carry Flag) */

Special function registers which are located on an address dividable by 8 are bit-addressable, an sbit addresses a specific bit within these sfr.

16 Bit and 32 bit special function register combinations which require a certain access order are better not declared using sfr16 or sfr32. Allthough SDCC usually accesses them Least Significant Byte (LSB) first, this is not guaranteed.

3.4.1.8

Pointers to MCS51/DS390 specific memory spaces

SDCC allows (via language extensions) pointers to explicitly point to any of the memory spaces of the 8051. In addition to the explicit pointers, the compiler uses (by default) generic pointers which can be used to point to any of the memory spaces.

Pointer declaration examples:

/* pointer physically in internal ram pointing to object in external ram */ xdata unsigned char * data p;

/* pointer physically in external ram pointing to object in internal ram */ data unsigned char * xdata p;

/* pointer physically in code rom pointing to data in xdata space */ xdata unsigned char * code p;

/* pointer physically in code space pointing to data in code space */ code unsigned char * code p;

/* the following is a generic pointer physically located in xdata space */ char * xdata p;

/* the following is a function pointer physically located in data space */ char (* data fp)(void);

Well you get the idea.

All unqualified pointers are treated as 3-byte (4-byte for the ds390) generic pointers.

The highest order byte of the generic pointers contains the data space information. Assembler support routines are called whenever data is stored or retrieved using generic pointers. These are useful for developing reusable library routines. Explicitly specifying the pointer type will generate the most efficient code.

3.4.1.9

Notes on MCS51 memory layout

The 8051 family of microcontrollers have a minimum of 128 bytes of internal RAM memory which is structured as follows:

- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R0 to R7,

- Bytes 20-2F - 16 bytes to hold 128 bit variables and,

30

3.4. STORAGE CLASS LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC

- Bytes 30-7F - 80 bytes for general purpose use.

Additionally some members of the MCS51 family may have up to 128 bytes of additional, indirectly addressable, internal RAM memory (idata). Furthermore, some chips may have some built in external memory (xdata) which should not be confused with the internal, directly addressable RAM memory (data). Sometimes this built in

xdata memory has to be activated before using it (you can probably find this information on the datasheet of the microcontroller your are using, see also section

3.11

Startup-Code).

Normally SDCC will only use the first bank of registers (register bank 0), but it is possible to specify that other banks of registers (keyword using ) should be used in interrupt routines. By default, the compiler will place the stack after the last byte of allocated memory for variables. For example, if the first 2 banks of registers are used, and only four bytes are used for data variables, it will position the base of the internal stack at address 20 (0x14).

This implies that as the stack grows, it will use up the remaining register banks, and the 16 bytes used by the 128 bit variables, and 80 bytes for general purpose use. If any bit variables are used, the data variables will be placed in unused register banks and after the byte holding the last bit variable. For example, if register banks 0 and 1 are used, and there are 9 bit variables (two bytes used), data variables will be placed starting from address 0x10 to 0x20 and continue at address 0x22. You can also use --data-loc to specify the start address of the data and --iram-size to specify the size of the total internal RAM (data+idata).

By default the 8051 linker will place the stack after the last byte of (i)data variables. Option --stack-loc allows you to specify the start of the stack, i.e. you could start it after any data in the general purpose area. If your microcontroller has additional indirectly addressable internal RAM (idata) you can place the stack on it. You may also need to use --xdata-loc to set the start address of the external RAM (xdata) and --xram-size to specify its size.

Same goes for the code memory, using --code-loc and --code-size. If in doubt, don’t specify any options and see if the resulting memory layout is appropriate, then you can adjust it.

The linker generates two files with memory allocation information. The first, with extension .map shows all the variables and segments. The second with extension .mem shows the final memory layout. The linker will complain either if memory segments overlap, there is not enough memory, or there is not enough space for stack. If you get any linking warnings and/or errors related to stack or segments allocation, take a look at either the .map or .mem

files to find out what the problem is. The .mem file may even suggest a solution to the problem.

3.4.2

Z80/Z180 Storage Class Language Extensions

3.4.2.1

sfr (in/out to 8-bit addresses)

The Z80 family has separate address spaces for memory and input/output memory. I/O memory is accessed with special instructions, e.g.: sfr at 0x78 IoPort; /* define a var in I/O space at 78h called IoPort */

Writing 0x01 to this variable generates the assembly code:

3E 01

D3 78 ld a,#0x01 out (_IoPort),a

3.4.2.2

banked sfr (in/out to 16-bit addresses)

The keyword banked is used to support 16 bit addresses in I/O memory e.g.: sfr banked at 0x123 IoPort;

Writing 0x01 to this variable generates the assembly code:

01 23 01 ld bc,#_IoPort

3E 01 ld a,#0x01

ED 79 out (c),a

3.4.2.3

sfr (in0/out0 to 8 bit addresses on Z180/HD64180)

The compiler option --portmode=180 (80) and a compiler #pragma portmode=z180 (z80) is used to turn on (off) the Z180/HD64180 port addressing instructions in0/out0 instead of in/out. If you include the file z180.h this will be set automatically.

31

3.5. ABSOLUTE ADDRESSING CHAPTER 3. USING SDCC

3.4.3

HC08 Storage Class Language Extensions

3.4.3.1

data

The data storage class declares a variable that resides in the first 256 bytes of memory (the direct page). The HC08 is most efficient at accessing variables (especially pointers) stored here.

3.4.3.2

xdata

The xdata storage class declares a variable that can reside anywhere in memory. This is the default if no storage class is specified.

3.5

Absolute Addressing

Data items can be assigned an absolute address with the at <address> keyword, in addition to a storage class, e.g.: xdata at 0x7ffe unsigned int chksum;

In the above example the variable chksum will be located at 0x7ffe and 0x7fff of the external ram. The compiler does not reserve any space for variables declared in this way (they are implemented with an equate in the assembler).

Thus it is left to the programmer to make sure there are no overlaps with other variables that are declared without the absolute address. The assembler listing file (.lst) and the linker output files (.rst) and (.map) are good places to look for such overlaps. Variables with an absolute address are not initialized.

In case of memory mapped I/O devices the keyword volatile has to be used to tell the compiler that accesses might not be removed: volatile xdata at 0x8000 unsigned char PORTA_8255;

For some architectures (mcs51) array accesses are more efficient if an (xdata/far) array starts at a block (256 byte) boundary (section

3.12.1

has an example).

Absolute addresses can be specified for variables in all storage classes, e.g.: bit at 0x02 bvar;

The above example will allocate the variable at offset 0x02 in the bit-addressable space. There is no real advantage to assigning absolute addresses to variables in this manner, unless you want strict control over all the variables allocated. One possible use would be to write hardware portable code. For example, if you have a routine that uses one or more of the microcontroller I/O pins, and such pins are different for two different hardwares, you can declare the I/O pins in your routine using: extern volatile bit MOSI; extern volatile bit MISO; extern volatile bit MCLK;

/* master out, slave in */

/* master in, slave out */

/* master clock */

/* Input and Output of a byte on a 3-wire serial bus.

If needed adapt polarity of clock, polarity of data and bit order

*/ unsigned char spi_io(unsigned char out_byte)

{ unsigned char i=8; do {

MOSI = out_byte & 0x80; out_byte < <= 1;

MCLK = 1;

/* _asm nop _endasm; */ if(MISO) out_byte += 1;

MCLK = 0;

} while(--i);

/* for slow peripherals */

32

3.6. PARAMETERS & LOCAL VARIABLES CHAPTER 3. USING SDCC return out_byte;

}

Then, someplace in the code for the first hardware you would use bit at 0x80 MOSI; bit at 0x81 MISO; bit at 0x82 MCLK;

/* I/O port 0, bit 0 */

/* I/O port 0, bit 1 */

/* I/O port 0, bit 2 */

Similarly, for the second hardware you would use bit at 0x83 MOSI; bit at 0x91 MISO; bit at 0x92 MCLK;

/* I/O port 0, bit 3 */

/* I/O port 1, bit 1 */

/* I/O port 1, bit 2 */ and you can use the same hardware dependent routine without changes, as for example in a library. This is somehow similar to sbit, but only one absolute address has to be specified in the whole project.

3.6

Parameters & Local Variables

Automatic (local) variables and parameters to functions can either be placed on the stack or in data-space. The default action of the compiler is to place these variables in the internal RAM (for small model) or external RAM

(for large model). This in fact makes them similar to static so by default functions are non-reentrant.

They can be placed on the stack by using the --stack-auto option, by using #pragma stackauto or by using the reentrant keyword in the function declaration, e.g.: unsigned char foo(char i) reentrant

{

...

}

Since stack space on 8051 is limited, the reentrant keyword or the --stack-auto option should be used sparingly.

Note that the reentrant keyword just means that the parameters & local variables will be allocated to the stack, it

does not mean that the function is register bank independent.

Local variables can be assigned storage classes and absolute addresses, e.g.: unsigned char foo()

{ xdata unsigned char i; bit bvar; data at 0x31 unsigned char j;

...

}

In the above example the variable i will be allocated in the external ram, bvar in bit addressable space and j in internal ram. When compiled with --stack-auto or when a function is declared as reentrant this should only be done for static variables.

Parameters however are not allowed any storage class, (storage classes for parameters will be ignored), their allocation is governed by the memory model in use, and the reentrancy options.

It is however allowed to use bit parameters in reentrant functions and also non-static local bit variables are supported. Efficient use is limited to 8 semi-bitregisters in bit space. They are pushed and popped to stack as a single byte just like the normal registers.

33

3.7. OVERLAYING CHAPTER 3. USING SDCC

3.7

Overlaying

For non-reentrant functions SDCC will try to reduce internal ram space usage by overlaying parameters and local variables of a function (if possible). Parameters and local variables of a function will be allocated to an overlayable segment if the function has no other function calls and the function is non-reentrant and the memory model is small.

If an explicit storage class is specified for a local variable, it will NOT be overlayed.

Note that the compiler (not the linkage editor) makes the decision for overlaying the data items. Functions that are called from an interrupt service routine should be preceded by a #pragma nooverlay if they are not reentrant.

Also note that the compiler does not do any processing of inline assembler code, so the compiler might incorrectly assign local variables and parameters of a function into the overlay segment if the inline assembler code calls other c-functions that might use the overlay. In that case the #pragma nooverlay should be used.

Parameters and local variables of functions that contain 16 or 32 bit multiplication or division will NOT be overlayed since these are implemented using external functions, e.g.:

#pragma save

#pragma nooverlay void set_error(unsigned char errcd)

{

P3 = errcd;

}

#pragma restore void some_isr () interrupt 2

{

...

set_error(10);

...

}

In the above example the parameter errcd for the function set_error would be assigned to the overlayable segment if the #pragma nooverlay was not present, this could cause unpredictable runtime behavior when called from an interrupt service routine. The #pragma nooverlay ensures that the parameters and local variables for the function are NOT overlayed.

3.8

Interrupt Service Routines

3.8.1

General Information

SDCC allows interrupt service routines to be coded in C, with some extended keywords.

void timer_isr (void) interrupt 1 using 1

{

...

}

The optional number following the interrupt keyword is the interrupt number this routine will service. When present, the compiler will insert a call to this routine in the interrupt vector table for the interrupt number specified.

If you have multiple source files in your project, interrupt service routines can be present in any of them, but a prototype of the isr MUST be present or included in the file that contains the function main. The optional using keyword can be used to tell the compiler to use the specified register bank (8051 specific) when generating code for this function.

Interrupt service routines open the door for some very interesting bugs:

If an interrupt service routine changes variables which are accessed by other functions these variables have to be declared volatile.

If the access to these variables is not atomic (i.e. the processor needs more than one instruction for the access and could be interrupted while accessing the variable) the interrupt must be disabled during the access to avoid

34

3.8. INTERRUPT SERVICE ROUTINES CHAPTER 3. USING SDCC inconsistent data. Access to 16 or 32 bit variables is obviously not atomic on 8 bit CPUs and should be protected by disabling interrupts. You’re not automatically on the safe side if you use 8 bit variables though. We need an example here: f.e. on the 8051 the harmless looking ”flags |= 0x80;” is not atomic if flags resides in xdata.

Setting ”flags |= 0x40;” from within an interrupt routine might get lost if the interrupt occurs at the wrong time.

”counter += 8;” is not atomic on the 8051 even if counter is located in data memory. Bugs like these are hard to reproduce and can cause a lot of trouble.

The return address and the registers used in the interrupt service routine are saved on the stack so there must be sufficient stack space. If there isn’t variables or registers (or even the return address itself) will be corrupted.

This stack overflow is most likely to happen if the interrupt occurs during the ”deepest” subroutine when the stack is already in use for f.e. many return addresses.

A special note here, int (16 bit) and long (32 bit) integer division, multiplication & modulus and floating-point operations are implemented using external support routines developed in ANSI-C. If an interrupt service routine needs to do any of these operations then the support routines (as mentioned in a following section) will have to be recompiled using the --stack-auto option and the source file will need to be compiled using the --int-long-reent compiler option.

Calling other functions from an interrupt service routine is not recommended, avoid it if possible. Note that when some function is called from an interrupt service routine it should be preceded by a #pragma nooverlay if it is not reentrant. Furthermore nonreentrant functions should not be called from the main program while the interrupt service routine might be active.

Also see section

3.7

about Overlaying and section

3.10

about Functions using private register banks.

3.8.2

MCS51/DS390 Interrupt Service Routines

Interrupt numbers and the corresponding address & descriptions for the Standard 8051/8052 are listed below.

SDCC will automatically adjust the interrupt vector table to the maximum interrupt number specified.

Interrupt #

3

4

5

0

1

2

Description

External 0

Timer 0

External 1

Timer 1

Serial

Timer 2 (8052)

Vector Address

0x0003

0x000B

0x0013

0x001B

0x0023

0x002B

If the interrupt service routine is defined without using a register bank or with register bank 0 (using 0), the compiler will save the registers used by itself on the stack upon entry and restore them at exit, however if such an interrupt service routine calls another function then the entire register bank will be saved on the stack. This scheme may be advantageous for small interrupt service routines which have low register usage.

If the interrupt service routine is defined to be using a specific register bank then only a, b, dptr & psw are saved and restored, if such an interrupt service routine calls another function (using another register bank) then the entire register bank of the called function will be saved on the stack. This scheme is recommended for larger interrupt service routines.

3.8.3

HC08 Interrupt Service Routines

Since the number of interrupts available is chip specific and the interrupt vector table always ends at the last byte of memory, the interrupt numbers corresponds to the interrupt vectors in reverse order of address. For example, interrupt 1 will use the interrupt vector at 0xfffc, interrupt 2 will use the interrupt vector at 0xfffa, and so on.

However, interrupt 0 (the reset vector at 0xfffe) is not redefinable in this way; instead see section

3.11

for details on customizing startup.

3.8.4

Z80 Interrupt Service Routines

The Z80 uses several different methods for determining the correct interrupt vector depending on the hardware implementation. Therefore, SDCC ignores the optional interrupt number and does not attempt to generate an interrupt vector table.

35

3.9. ENABLING AND DISABLING INTERRUPTS CHAPTER 3. USING SDCC

By default, SDCC generates code for a maskable interrupt, which uses an RETI instruction to return from the interrupt. To write an interrupt handler for the non-maskable interrupt, which needs an RETN instruction instead, add the critical keyword: void nmi_isr (void) critical interrupt

{

...

}

3.9

Enabling and Disabling Interrupts

3.9.1

Critical Functions and Critical Statements

A special keyword may be associated with a block or a function declaring it as critical. SDCC will generate code to disable all interrupts upon entry to a critical function and restore the interrupt enable to the previous state before returning. Nesting critical functions will need one additional byte on the stack for each call.

int foo () critical

{

...

...

}

The critical attribute maybe used with other attributes like reentrant.

The keyword critical may also be used to disable interrupts more locally: critical{ i++; }

More than one statement could have been included in the block.

3.9.2

Enabling and Disabling Interrupts directly

Interrupts can also be disabled and enabled directly (8051):

EA = 0;

...

EA = 1; or: EA_SAVE = EA;

EA = 0;

...

EA = EA_SAVE;

On other architectures which have seperate opcodes for enabling and disabling interrupts you might want to make use of defines with inline assembly (HC08):

#define CLI _asm cli _endasm;

#define SEI _asm sei _endasm;

...

Note: it is sometimes sufficient to disable only a specific interrupt source like f.e. a timer or serial interrupt by manipulating an interrupt mask register.

Usually the time during which interrupts are disabled should be kept as short as possible. This minimizes both

interrupt latency (the time between the occurrence of the interrupt and the execution of the first code in the interrupt routine) and interrupt jitter (the difference between the shortest and the longest interrupt latency). These really are something different, f.e. a serial interrupt has to be served before its buffer overruns so it cares for the maximum interrupt latency, whereas it does not care about jitter. On a loudspeaker driven via a digital to analog converter which is fed by an interrupt a latency of a few milliseconds might be tolerable, whereas a much smaller jitter will be very audible.

You can reenable interrupts within an interrupt routine and on some architectures you can make use of two

(or more) levels of interrupt priorities. On some architectures which don’t support interrupt priorities these can be implemented by manipulating the interrupt mask and reenabling interrupts within the interrupt routine. Check there is sufficient space on the stack and don’t add complexity unless you have to.

36

3.10. FUNCTIONS USING PRIVATE REGISTER BANKS (MCS51/DS390) CHAPTER 3. USING SDCC

3.9.3

Semaphore locking (mcs51/ds390)

Some architectures (mcs51/ds390) have an atomic bit test and clear instruction. These type of instructions are typically used in preemptive multitasking systems, where a routine f.e. claims the use of a data structure (’acquires a lock on it’), makes some modifications and then releases the lock when the data structure is consistent again. The instruction may also be used if interrupt and non-interrupt code have to compete for a resource. With the atomic bit test and clear instruction interrupts don’t have to be disabled for the locking operation.

SDCC generates this instruction if the source follows this pattern: volatile bit resource_is_free; if (resource_is_free)

{ resource_is_free=0;

...

resource_is_free=1;

}

Note, mcs51 and ds390 support only an atomic bit test and clear instruction (as opposed to atomic bit test and set).

3.10

Functions using private register banks (mcs51/ds390)

Some architectures have support for quickly changing register sets. SDCC supports this feature with the using attribute (which tells the compiler to use a register bank other than the default bank zero). It should only be applied to interrupt functions (see footnote below). This will in most circumstances make the generated ISR code more efficient since it will not have to save registers on the stack.

The using attribute will have no effect on the generated code for a non-interrupt function (but may occasionally

be useful anyway

2

).

(pending: I don’t think this has been done yet)

An interrupt function using a non-zero bank will assume that it can trash that register bank, and will not save it. Since high-priority interrupts can interrupt low-priority ones on the 8051 and friends, this means that if a highpriority ISR using a particular bank occurs while processing a low-priority ISR using the same bank, terrible and bad things can happen. To prevent this, no single register bank should be used by both a high priority and a low priority ISR. This is probably most easily done by having all high priority ISRs use one bank and all low priority

ISRs use another. If you have an ISR which can change priority at runtime, you’re on your own: I suggest using the default bank zero and taking the small performance hit.

It is most efficient if your ISR calls no other functions. If your ISR must call other functions, it is most efficient if those functions use the same bank as the ISR (see note 1 below); the next best is if the called functions use bank zero. It is very inefficient to call a function using a different, non-zero bank from an ISR.

3.11

Startup Code

3.11.1

MCS51/DS390 Startup Code

The compiler inserts a call to the C routine _sdcc_external_startup() at the start of the CODE area. This routine is in the runtime library. By default this routine returns 0, if this routine returns a non-zero value, the static & global variable initialization will be skipped and the function main will be invoked. Otherwise static & global variables will be initialized before the function main is invoked. You could add a _sdcc_external_startup() routine to your program to override the default if you need to setup hardware or perform some other critical operation prior to static

& global variable initialization. On some mcs51 variants xdata memory has to be explicitly enabled before it can be accessed or if the watchdog needs to be disabled, this is the place to do it. The startup code clears all internal data memory, 256 bytes by default, but from 0 to n-1 if --iram-sizen is used. (recommended for Chipcon CC1010).

See also the compiler option --no-xinit-opt and section

4.1

about MCS51-variants.

2 possible exception: if a function is called ONLY from ’interrupt’ functions using a particular bank, it can be declared with the same ’using’ attribute as the calling ’interrupt’ functions. For instance, if you have several ISRs using bank one, and all of them call memcpy(), it might make sense to create a specialized version of memcpy() ’using 1’, since this would prevent the ISR from having to save bank zero to the stack on entry and switch to bank zero before calling the function

37

3.12. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC

3.11.2

HC08 Startup Code

The HC08 startup code follows the same scheme as the MCS51 startup code.

3.11.3

Z80 Startup Code

On the Z80 the startup code is inserted by linking with crt0.o which is generated from sdcc/device/lib/z80/crt0.s. If you need a different startup code you can use the compiler option --no-std-crt0 and provide your own crt0.o.

3.12

Inline Assembler Code

3.12.1

A Step by Step Introduction

Starting from a small snippet of c-code this example shows for the MCS51 how to use inline assembly, access variables, a function parameter and an array in xdata memory. The example uses an MCS51 here but is easily adapted for other architectures. This is a buffer routine which should be optimized: unsigned char far at 0x7f00 buf[0x100]; unsigned char head,tail; void to_buffer( unsigned char c )

{ if( head != tail-1 ) buf[ head++ ] = c; /* access to a 256 byte aligned array */

}

If the code snippet (assume it is saved in buffer.c) is compiled with SDCC then a corresponding buffer.asm file is generated. We define a new function to_buffer_asm() in file buffer.c in which we cut and paste the generated code, removing unwanted comments and some ’:’. Then add ”_asm” and ”_endasm;” to the beginning and the end of the function body:

/* With a cut and paste from the .asm file, we have something to start with.

The function is not yet OK! (registers aren’t saved) */ void to_buffer_asm( unsigned char c )

{

_asm mov r2,dpl

;buffer.c if( head != tail-1 ) mov a,_tail dec a mov r3,a mov a,_head cjne a,ar3,00106$ ret

00106$:

;buffer.c buf[ head++ ] = c; /* access to a 256 byte aligned array */ mov r3,_head inc _head mov dpl,r3 mov dph,#(_buf > > 8) mov a,r2 movx @dptr,a

00103$: ret

_endasm;

}

The new file buffer.c should compile with only one warning about the unreferenced function argument ’c’. Now we hand-optimize the assembly code and insert an #define USE_ASSEMBLY (1) and finally have:

38

3.12. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC unsigned char far at 0x7f00 buf[0x100]; unsigned char head,tail;

#define USE_ASSEMBLY (1)

#if !USE_ASSEMBLY

void to_buffer( unsigned char c )

{ if( head != tail-1 ) buf[ head++ ] = c;

}

#else void to_buffer( unsigned char c )

{ c; // to avoid warning: unreferenced function argument

_asm

; save used registers here.

; If we were still using r2,r3 we would have to push them here.

; if( head != tail-1 ) mov a,_tail dec a xrl a,_head

; we could do an ANL a,#0x0f here to use a smaller buffer (see below) jz t_b_end$

;

; buf[ head++ ] = c; mov a,dpl ; dpl holds lower byte of function argument mov dpl,_head ; buf is 0x100 byte aligned so head can be used directly mov dph,#(_buf> >8) movx @dptr,a inc _head

; we could do an ANL _head,#0x0f here to use a smaller buffer (see above) t_b_end$:

; restore used registers here

_endasm;

}

#endif

The inline assembler code can contain any valid code understood by the assembler, this includes any assembler di-

rectives and comment lines

3

. The compiler does not do any validation of the code within the _asm ...

_endasm; keyword pair. Specifically it will not know which registers are used and thus register pushing/popping has to be done manually.

It is recommended that each assembly instruction (including labels) be placed in a separate line (as the example shows). When the --peep-asm command line option is used, the inline assembler code will be passed through the peephole optimizer. There are only a few (if any) cases where this option makes sense, it might cause some unexpected changes in the inline assembler code. Please go through the peephole optimizer rules defined in file

SDCCpeeph.def before using this option.

3.12.2

Naked Functions

A special keyword may be associated with a function declaring it as _naked. The _naked function modifier attribute prevents the compiler from generating prologue and epilogue code for that function. This means that the user is entirely responsible for such things as saving any registers that may need to be preserved, selecting the proper

3

The assembler does not like some characters like ’:’ or ”’ in comments.

You’ll find an 100+ pages assembler manual in sdcc/as/doc/asxhtm.html

39

3.12. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC register bank, generating the return instruction at the end, etc. Practically, this means that the contents of the function must be written in inline assembler. This is particularly useful for interrupt functions, which can have a large (and often unnecessary) prologue/epilogue. For example, compare the code generated by these two functions: volatile data unsigned char counter; void simpleInterrupt(void) interrupt 1

{ counter++;

} void nakedInterrupt(void) interrupt 2 _naked

{

_asm inc reti

_endasm;

_counter ; does not change flags, no need to save psw

; MUST explicitly include ret or reti in _naked function.

}

For an 8051 target, the generated simpleInterrupt looks like:

_simpleInterrupt: push acc push push b dpl push push mov inc dph psw psw,#0x00

_counter pop pop pop pop pop reti psw dph dpl b acc whereas nakedInterrupt looks like:

_nakedInterrupt: inc _counter ; does not change flags, no need to save psw reti ; MUST explicitly include ret or reti in _naked function

The related directive #pragma exclude allows a more fine grained control over pushing & popping the registers.

While there is nothing preventing you from writing C code inside a _naked function, there are many ways to shoot yourself in the foot doing this, and it is recommended that you stick to inline assembler.

3.12.3

Use of Labels within Inline Assembler

SDCC allows the use of in-line assembler with a few restrictions regarding labels. In older versions of the compiler all labels defined within inline assembler code had to be of the form nnnnn$ where nnnn is a number less than 100

(which implies a limit of utmost 100 inline assembler labels per function).

_asm mov

00001$: djnz

_endasm ; b,#10 b,00001$

40

3.13. INTERFACING WITH ASSEMBLER CODE CHAPTER 3. USING SDCC

Inline assembler code cannot reference any C-Labels, however it can reference labels defined by the inline assembler, e.g.: foo() {

/* some c code */

_asm

; some assembler code ljmp $0003

_endasm;

/* some more c code */ clabel: /* inline assembler cannot reference this label */

_asm

$0003: ;label (can be referenced by inline assembler only)

_endasm ;

/* some more c code */

}

In other words inline assembly code can access labels defined in inline assembly within the scope of the function.

The same goes the other way, i.e. labels defines in inline assembly can not be accessed by C statements.

3.13

Interfacing with Assembler Code

3.13.1

Global Registers used for Parameter Passing

The compiler always uses the global registers DPL, DPH, B and ACC to pass the first parameter to a routine. The second parameter onwards is either allocated on the stack (for reentrant routines or if --stack-auto is used) or in data

/ xdata memory (depending on the memory model).

3.13.2

Assembler Routine (non-reentrant)

In the following example the function c_func calls an assembler routine asm_func, which takes two parameters.

extern int asm_func(unsigned char, unsigned char); int c_func (unsigned char i, unsigned char j)

{ return asm_func(i,j);

} int main()

{ return c_func(10,9);

}

The corresponding assembler function is:

.globl _asm_func_PARM_2

.globl _asm_func

.area OSEG

_asm_func_PARM_2:

.ds 1

.area CSEG

_asm_func: mov add mov mov ret a,dpl a,_asm_func_PARM_2 dpl,a dph,#0x00

41

3.13. INTERFACING WITH ASSEMBLER CODE CHAPTER 3. USING SDCC

Note here that the return values are placed in ’dpl’ - One byte return value, ’dpl’ LSB & ’dph’ MSB for two byte values. ’dpl’, ’dph’ and ’b’ for three byte values (generic pointers) and ’dpl’,’dph’,’b’ & ’acc’ for four byte values.

The parameter naming convention is _<function_name>_PARM_<n>, where n is the parameter number starting from 1, and counting from the left. The first parameter is passed in “dpl” for a one byte parameter, “dptr” for two bytes, “b,dptr” for three bytes and “acc,b,dptr” for a four bytes parameter. The variable name for the second parameter will be _<function_name>_PARM_2.

Assemble the assembler routine with the following command:

asx8051 -losg asmfunc.asm

Then compile and link the assembler routine to the C source file with the following command:

sdcc cfunc.c asmfunc.rel

3.13.3

Assembler Routine (reentrant)

In this case the second parameter onwards will be passed on the stack, the parameters are pushed from right to left i.e. after the call the leftmost parameter will be on the top of the stack. Here is an example: extern int asm_func(unsigned char, unsigned char); int c_func (unsigned char i, unsigned char j) reentrant

{ return asm_func(i,j);

} int main()

{ return c_func(10,9);

}

The corresponding assembler routine is:

.globl _asm_func

_asm_func: push _bp mov _bp,sp mov r2,dpl mov a,_bp add a,#0xfd mov r0,a add a,#0xfc ;?

mov r1,a mov a,@r0 add a,r2 ;?

mov dpl,a mov dph,#0x00 mov sp,_bp pop _bp ret

The compiling and linking procedure remains the same, however note the extra entry & exit linkage required for the assembler code, _bp is the stack frame pointer and is used to compute the offset into the stack for parameters and local variables.

42

3.14. INT (16 BIT) AND LONG (32 BIT) SUPPORT CHAPTER 3. USING SDCC

3.14

int (16 bit) and long (32 bit) Support

For signed & unsigned int (16 bit) and long (32 bit) variables, division, multiplication and modulus operations are implemented by support routines. These support routines are all developed in ANSI-C to facilitate porting to other

MCUs, although some model specific assembler optimizations are used. The following files contain the described routines, all of them can be found in <installdir>/share/sdcc/lib.

Function Description

_mulint.c

_divsint.c

_divuint.c

_modsint.c

_moduint.c

_mullong.c

_divslong.c

_divulong.c

16 bit multiplication signed 16 bit division (calls _divuint) unsigned 16 bit division signed 16 bit modulus (calls _moduint) unsigned 16 bit modulus

32 bit multiplication signed 32 division (calls _divulong) unsigned 32 division

_modslong.c

signed 32 bit modulus (calls _modulong)

_modulong.c

unsigned 32 bit modulus

Since they are compiled as non-reentrant, interrupt service routines should not do any of the above operations.

If this is unavoidable then the above routines will need to be compiled with the --stack-auto option, after which the source program will have to be compiled with --int-long-reent option. Notice that you don’t have to call these routines directly. The compiler will use them automatically every time an integer operation is required.

3.15

Floating Point Support

SDCC supports IEEE (single precision 4 bytes) floating point numbers.The floating point support routines are derived from gcc’s floatlib.c and consist of the following routines:

Function Description

_fsadd.c

_fssub.c

_fsdiv.c

_fsmul.c

_fs2uchar.c

_fs2char.c

_fs2uint.c

add floating point numbers subtract floating point numbers divide floating point numbers multiply floating point numbers convert floating point to unsigned char convert floating point to signed char convert floating point to unsigned int

_fs2int.c

_fs2ulong.c

_fs2long.c

_uchar2fs.c

_char2fs.c

convert floating point to signed int convert floating point to unsigned long convert floating point to signed long convert unsigned char to floating point convert char to floating point number

_uint2fs.c

_int2fs.c

convert unsigned int to floating point convert int to floating point numbers

_ulong2fs.c

convert unsigned long to floating point number

_long2fs.c

convert long to floating point number

These support routines are developed in ANSI-C so there is room for space and speed improvement

4

. Note if

all these routines are used simultaneously the data space might overflow. For serious floating point usage the large model might be needed. Also notice that you don’t have to call this routines directly. The compiler will use them automatically every time a floating point operation is required.

4

The floating point routines for the mcs51 are implemented in assembler

43

3.16. LIBRARY ROUTINES CHAPTER 3. USING SDCC

3.16

Library Routines

<pending: this is messy and incomplete - a little more information is in sdcc/doc/libdoc.txt >

3.16.1

Compiler support routines (_gptrget, _mulint etc.)

3.16.2

Stdclib functions (puts, printf, strcat etc.)

3.16.2.1

<stdio.h>

As usual on embedded systems you have to provide your own getchar() and putchar() routines. SDCC does not know whether the system connects to a serial line with or without handshake, LCD, keyboard or other device.

You’ll find examples for serial routines f.e. in sdcc/device/lib.

The default printf()implementation in printf_large.c does not support float (except on ds390). To enable this recompile it with the option -DUSE_FLOATS=1 on the command line. Use--model-large for the mcs51 port, since this uses a lot of memory.

If you’re short on memory you might want to use printf_small() instead of printf(). For the mcs51 there additionally are assembly versions printf_tiny() and printf_fast() and printf_fast_f() which should fit the requirements of many embedded systems (printf_fast() can be customized by unsetting #defines to not support long variables and field widths).

3.16.3

Math functions (sin, pow, sqrt etc.)

3.16.4

Other libraries

Libraries included in SDCC should have a license at least as liberal as the GNU Lesser General Public License

LGPL.

If you have ported some library or want to share experience about some code which f.e. falls into any of these categories Busses (I2C, CAN, Ethernet, Profibus, Modbus, USB, SPI, JTAG ...), Media (IDE, Memory cards, eeprom, flash...), En-/Decryption, Remote debugging, Realtime kernel, Keyboard, LCD, RTC, FPGA, PID then the sdcc-user mailing list http://sourceforge.net/mail/?group_id=599 would certainly like to hear about it.

Programmers coding for embedded systems are not especially famous for being enthusiastic, so don’t expect a big hurray but as the mailing list is searchable these references are very valuable. Let’s help to create a climate where information is shared.

3.17

Memory Models

3.17.1

MCS51 Memory Models

3.17.1.1

Small, Medium and Large

SDCC allows three memory models for MCS51 code, small, medium and large. Modules compiled with different memory models should never be combined together or the results would be unpredictable. The library routines supplied with the compiler are compiled as small, medium and large. The compiled library modules are contained in separate directories as small, medium and large so that you can link to the appropriate set.

When the medium or large model is used all variables declared without a storage class will be allocated into the external ram, this includes all parameters and local variables (for non-reentrant functions). When the small model is used variables without storage class are allocated in the internal ram.

Judicious usage of the processor specific storage classes and the ’reentrant’ function type will yield much more efficient code, than using the large model. Several optimizations are disabled when the program is compiled using the large model, it is therefore recommended that the small model be used unless absolutely required.

3.17.1.2

External Stack

The external stack (--xstack option) is located in pdata memory (usually at the start of the external ram segment) and uses all unused space in pdata (max. 256 bytes). When --xstack option is used to compile the program, the parameters and local variables of all reentrant functions are allocated in this area. This option is provided for programs with large stack space requirements. When used with the --stack-auto option, all parameters and local

44

3.18. PRAGMAS CHAPTER 3. USING SDCC variables are allocated on the external stack (note: support libraries will need to be recompiled with the same options. There is a predefined target in the library makefile).

The compiler outputs the higher order address byte of the external ram segment into port P2 (see also section

4.1

), therefore when using the External Stack option, this port may not be used by the application program.

3.17.2

DS390 Memory Model

The only model supported is Flat 24. This generates code for the 24 bit contiguous addressing mode of the Dallas

DS80C390 part. In this mode, up to four meg of external RAM or code space can be directly addressed. See the data sheets at www.dalsemi.com for further information on this part.

Note that the compiler does not generate any code to place the processor into 24 bitmode (although tinibios in the ds390 libraries will do that for you). If you don’t use tinibios, the boot loader or similar code must ensure that the processor is in 24 bit contiguous addressing mode before calling the SDCC startup code.

Like the --model-large option, variables will by default be placed into the XDATA segment.

Segments may be placed anywhere in the 4 meg address space using the usual --*-loc options. Note that if any segments are located above 64K, the -r flag must be passed to the linker to generate the proper segment relocations, and the Intel HEX output format must be used. The -r flag can be passed to the linker by using the option -Wl-r on the SDCC command line. However, currently the linker can not handle code segments > 64k.

3.18

Pragmas

SDCC supports the following #pragma directives:

• save - this will save all current options to the save/restore stack. See #pragma restore.

• restore - will restore saved options from the last save. saves & restores can be nested. SDCC uses a save/restore stack: save pushes current options to the stack, restore pulls current options from the stack. See

#pragma save.

• callee_saves function1[,function2[,function3...]] - The compiler by default uses a caller saves convention for register saving across function calls, however this can cause unnecessary register pushing & popping when calling small functions from larger functions. This option can be used to switch off the register saving convention for the function names specified. The compiler will not save registers when calling these functions, extra code need to be manually inserted at the entry & exit for these functions to save & restore the registers used by these functions, this can SUBSTANTIALLY reduce code & improve run time performance of the generated code. In the future the compiler (with inter procedural analysis) may be able to determine the appropriate scheme to use for each function call. If --callee-saves command line option is used, the function names specified in #pragma callee_saves is appended to the list of functions specified in the command line.

• exclude none | {acc[,b[,dpl[,dph]]] - The exclude pragma disables the generation of pairs of push/pop instructions in Interrupt Service Routines. The directive should be placed immediately before the ISR function definition and it affects ALL ISR functions following it. To enable the normal register saving for ISR functions use #pragma exclude none. See also the related keyword _naked.

• less_pedantic - the compiler will not warn you anymore for obvious mistakes, you’r on your own now ;-(

• disable_warning <nnnn> - the compiler will not warn you anymore about warning number <nnnn>.

• nogcse - will stop global common subexpression elimination.

• noinduction - will stop loop induction optimizations.

• noinvariant - will not do loop invariant optimizations. For more details see Loop Invariants in section

8.1.4

.

45

3.18. PRAGMAS CHAPTER 3. USING SDCC

• noiv - Do not generate interrupt vector table entries for all ISR functions defined after the pragma. This is useful in cases where the interrupt vector table must be defined manually, or when there is a secondary, manually defined interrupt vector table (e.g. for the autovector feature of the Cypress EZ-USB FX2). More elegantly this can be achieved by obmitting the optional interrupt number after the interrupt keyword, see section

3.8

about interrupts.

• nojtbound - will not generate code for boundary value checking, when switch statements are turned into jump-tables (dangerous). For more details see section

8.1.7

.

• noloopreverse - Will not do loop reversal optimization

• nooverlay - the compiler will not overlay the parameters and local variables of a function.

• stackauto- See option --stack-auto and section

3.6

Parameters and Local Variables.

• opt_code_speed - The compiler will optimize code generation towards fast code, possibly at the expense of code size.

• opt_code_size - The compiler will optimize code generation towards compact code, possibly at the expense of code speed.

• opt_code_balanced - The compiler will attempt to generate code that is both compact and fast, as long as meeting one goal is not a detriment to the other (this is the default).

• std_sdcc89 - Generally follow the C89 standard, but allow SDCC features that conflict with the standard

(default).

• std_c89 - Follow the C89 standard and disable SDCC features that conflict with the standard.

• std_sdcc99 - Generally follow the C99 standard, but allow SDCC features that conflict with the standard

(incomplete support).

• std_c99 - Follow the C99 standard and disable SDCC features that conflict with the standard (incomplete support).

• codeseg <name>- Use this name (max. 8 characters) for the code segment.

• constseg <name>- Use this name (max. 8 characters) for the const segment.

SDCPP supports the following #pragma directives:

• preproc_asm (+ | -) - switch _asm _endasm block preprocessing on / off. Default is on.

The pragma’s are intended to be used to turn-on or off certain optimizations which might cause the compiler to generate extra stack / data space to store compiler generated temporary variables. This usually happens in large functions. Pragma directives should be used as shown in the following example, they are used to control options

& optimizations for a given function; pragmas should be placed before and/or after a function, placing pragma’s inside a function body could have unpredictable results.

#pragma save

#pragma nogcse

/* save the current settings */

/* turnoff global subexpression elimination */

#pragma noinduction /* turn off induction optimizations */ int foo ()

{

...

/* large code */

...

}

#pragma restore /* turn the optimizations back on */

The compiler will generate a warning message when extra space is allocated. It is strongly recommended that the save and restore pragma’s be used when changing options for a function.

46

3.19. DEFINES CREATED BY THE COMPILER CHAPTER 3. USING SDCC

3.19

Defines Created by the Compiler

The compiler creates the following #defines:

#define Description

SDCC this Symbol is always defined

SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc depending on the model used (e.g.: -mds390

__mcs51, __ds390, __hc08, __z80, etc

SDCC_STACK_AUTO

SDCC_MODEL_SMALL depending on the model used (e.g. -mz80) when --stack-auto option is used when --model-small is used

SDCC_MODEL_MEDIUM

SDCC_MODEL_LARGE

SDCC_USE_XSTACK

SDCC_STACK_TENBIT

SDCC_MODEL_FLAT24 when --model-medium is used when --model-large is used when --xstack option is used when -mds390 is used when -mds390 is used

47

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents