Sdcc Compiler

[Allen Yerke]

TheSmall Device C Compiler (SDCC) is a free-software, partially retargetable[1] C compiler for 8-bit microcontrollers. It is distributed under the GNU General Public License. The package also contains an assembler, linker, simulator and debugger. As of March 2007, SDCC is the only open-source C compiler for Intel 8051-compatible microcontrollers.[2][3][4][citation needed]In 2011 the compiler was downloaded on average more than 200 times per day.[5]

I'm trying to compile some c-code that was originally written for SDCC using GCC to run some unit tests on a host computer.There are some language extensions for SDCC like __xdata or __pdata (for memory control) which should remain for SDCC but that should be ignored when compiled with GCC. I would strongly prefer not to modify the modules under test. Is there any way to do this?

I already figured out that it works if I add something like #define __xdata in the module under test. Maybe it is possible to have something like a "global definition" therefore? I have little experience with the GCC. Maybe there are compiler flags that could help me?

Small Device C Compiler (SDCC) is a free opensource (GPL) C compiler for 8051 based microcontrollers .It consists of linker, assembler, simulator and debugger for developing software for the 8051 architecture.

Now most of the hex file downloaders will not recognize the .ihx format.To convert the ihx format to hex format you have to use another program called packihx which will repackage ihx to hex format.

For low-level programming, sometimes it's necessary to say, at a given memory location, this is where my address is. For this post, the example is the PIR1 register in the PIC16F886 and related microcontrollers. It's always found at address 0x000C.

now I can assign to the variable with something like pir1 = 0x40 (okay, I'd use a #defined constant instead of magic numbers but you get my drift). This compiles just fine on GCC, with no warnings even when I use -Wextra -Wall. To check my assumptions, GCC spits out the following x86_64:

The standard way for absolute addressing in SDCC is via compiler extensions, but you're doing it wrongly. __code __at (0xc) uint8_t PIR1; puts the variable in the code section which isn't writable. That's why you see the error error 33: Attempt to assign value to a constant variable (=). Remember PIC14 uses Harvard architecture. If the address is in RAM then use

"warning 88: cast of LITERAL value to 'generic' pointer" appears to be a false positive. There is nothing wrong syntax-wise or language-wise with your macro. The C standard explicitly allows such conversions, see C17 6.3.2.3/5:

An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Embedded systems compilers in general and PIC compilers in particular, have a bad reputation of non-compliance to standard C. So you either have to figure out how to disable the broken warning or consider using a different compiler.

However the output file is padded with zeros between location 0x0000 and 0x7FFF, followed by the code at the specified location.The reason I want to choose 0x8000 is because of the absolute addressing generated within the compiled z80 file by sdcc. If I instead set the code location to 0x0000 then load into 0x8000 at a later stage then the program will fail.

On a separate note, I wondered how older machines handled programs which were loaded in at variable memory addresses without affecting the absolute memory jumps / calls within the program.I'm assuming this wasn't an option for say the C64 or spectrum and the load address is predetermined at point of compilation and non changeable.

Here on StackOverflow recommendations are off-topic, so please use your web search skills to find a better tool. Optimally it is controlled by command line parameters for easy integration into your build process by makefile or shell script. If you do, you will find for example srecord, which despite its name knows how to handle Intelhex and binary files, too.

Older machines cannot load programs with absolute addresses in them at arbitrary offsets and run them without changes. As you noticed, they will not work because the absolute addresses are correct only at the specific offset.

CP/M programs are loaded always at offset 0x0100, for example. If such a program wants to run at another offset, it starts by copying itself to the target range and patching all absolute addresses in its machine code. There is no automagic to do this, each program needs to provide its own patching routine. I did this many years ago for a debugger.

Not so old machines like the Atari ST enrich their executable files with relocation sections. These define in a general way how to patch the loaded binary to the target address. The loader of the operating system patches the loaded code before it jumps to the entry point of the program.

Some processors allow relative addresses for jumps or data access. However, these are commonly limited in their "mileage" to their near neighborhood. Some compilers even support the creation of such position-independent programs.

The SDCC (Small Devices C Compiler) is a free C compiler developed for 8-bit microcontrollers. This application note demonstrates how to use the SDCC to develop firmware for the DS89C430/450 family of ultra-high-speed 8051-compatible microcontrollers. Installing the SDCC free C compiler is also explained.

The SDCC (Small Devices C Compiler) is a free C compiler developed for 8-bit microcontrollers. Although compatible with many different architectures, the SDCC compiler has extended support for devices based on the 8051-core. This application note will focus on using the SDCC to develop firmware for the DS89C430/450 family of ultra-high-speed 8051-compatible microcontrollers from Maxim/Dallas Semiconductor.

The SDCC is a command line, firmware development tool that includes a preprocessor, a compiler, an assembler, a linker, and an optimizer. Also bundled with the install file is the SDCDB, a source level debugger similar to gdb (GNU Debugger). When an error-free program is compiled and linked with the SDCC, a Load Module in Intel hex format is created. This file can then be loaded into the DS89C430/450 microcontroller's flash memory using a Serial Loader. (See DS89C430/450 documentation and application notes for details on downloading firmware to device).

For the most up-to-date information about the SDCC, visit or read the SDCC manual, sdccman.pdf (copied to your hard drive during installation). Questions can also be submitted to the online SDCC message forum or mailing list which can be found in the "Support" section of the SDCC webpage.

To install the SDCC, download the latest version from the "Download" section of the SDCC website at Although nightly builds of the software are available, it is usually safest to download the latest fully tested release version.

On the "Download" page, builds of the SDCC are available for several different operating systems. If you are working on a PC running Microsoft Windows, download the win32 self-executing SDCC install file and run the executable.

When installing the program, a prompt will appear asking to add the directory containing the program binaries to your path. This is recommended, and the remainder of this application note will assume that the user has done so.

To ensure that the SDCC installed correctly on your hard drive, open a Command Prompt and type sdcc --version. Press [Enter], and the text displayed in Figure 1 should appear in the window (actual text will depend on the SDCC version that you downloaded):

Save the file in plain ASCII format (i.e., using Microsoft Notepad). In the Command Prompt, type sdcc sdcctest.c and press [Enter]. If nothing appears, as shown in Figure 2, the program compiled successfully.

The SDCC supports most ANSI-C data types. The SDCC also supports a number of extended data types (also called storage classes) to take advantage of the 8051-architecture. They are presented in the following subsections with examples.

Unlike some commercial 8051 microcontroller development tools, the SDCC is only capable of declaring Special Function Registers as both bit and byte addressable. Although supported by the 8051 assembly language, shared bit and byte addressable RAM is not supported by the SDCC. To prove this, observe the following code sample and compiled assembler code.

Although the bit fields in declaration of "a" appear to be bit-addressable memory, the assembly listing (taken from the .rst file generated by SDCC) shows that the variable does not use bit addressing. In the listing do not confuse "a" and "_a". The "a" refers to the accumulator while the "_a" refers to the variable.

Declaring a variable with the near or data storage class places the variable in directly addressable RAM in the 8051-core. The DS89C430/450 family of microcontrollers has 128 bytes of directly addressable memory available. This is the fastest type of memory that can be accessed by the 8051, and the assembly code generated to read or write data in this area of RAM requires a single MOV instruction.

Declaring a variable with the far or xdata storage class places the variable in external RAM. Although this gives the developer access to a much larger RAM space, the assembly code generated to read and write to this memory uses a MOVX instruction which requires loading the external memory address into the data pointer.

The DS89C430/450 family of microcontrollers includes a 1 kilobyte internal SRAM that can be used for variables declared with far/xdata. Note that the DME1:0 bits in the Power Management Register (PMR) must be set for internal SRAM mode before this memory can be initialized or used.

3a8082e126