Philipp Klaus Krause | 6 Oct 17:35 2015

Should malloc() and friends be reentrent?

We are planning to replace SDCC'c current two memory allocators by a new
one. In one of the curent two (used in mcs51, ds390, hc08) malloc() and
friends code is in a critical section, in the other, it is not.

We have not yet decided which way the new allocator should go here.

Advantages of critical section inside malloc(): malloc() can be called
from interrupt handlers, multiple threads from OSses without any support
on the OS side.
Advantages of malloc() not having critical sections: Lower interupt
latency, since malloc() can then be interrupted.

When malloc() does not have critical sections, it is still possible to
get the advantages and disadvatages by wrapping all calls to malloc() in
critical sections (like e.g. the pvPortMalloc from FreeRTOS does).


Sdcc-user mailing list
Georg Icking-Konert | 2 Oct 18:58 2015

STM8 RAM code execution

hello all,

may I bother you again with a question about how to execute code in the RAM of STM8…?

For routines in RAM (as mandatory for STM8 flash block write/erase), I understand the steps are:

  1. compile & link routine for address in RAM —> 
        works now using #pragma in C code and —codeseg for linker (see [bugs:#2421]; thanks to Ben Shi!)

  2. tell linker to reserve flash space for above RAM routine (required for step 3) —> 
        I implemented an unused routine which contains N _nop_ operations. But isn’t there an easier way, e.g. "const code byte buf[N]“ or so…?

  3. modify hexfile to move RAM code to flash address, so after upload and reset a copy of the RAM routine is in flash —>
        haven’t done that yet. I have to look into srecord like Maarten proposed below

  4. during STM8 initialization copy routine from flash to RAM. Specifically, get src, dst and length, and copy to RAM —>
        under please find a file where I try to do this in assembler, because linker labels are only accessible via assembler…? This is my first "real“ assembler code, so I’m not quite sure it’ll do the job. Would you please be so kind and have a look at it?

  5. when required call RAM routine by name from C
        this should work, since the linker label still points to RAM…?

Can you please check if my understanding is correct? For your help thanks a lot in advance and have a nice day!

Regards, Georg

Am 29.09.2015 um 21:46 schrieb Maarten Brock <>:

You have to link at the ram address else all jumps and calls to it will jump to flash. You'll have to post-process the generated hex-file to move the section to an address in flash. And you'll have to use memcpy to copy it from flash to ram. You can use srecord for the post-processing.

The linker does create symbols with the start address and length but they are accessable from assembly only. Some small pieces of inline assembly should be able to fetch them for you.

int get_length(void) { volatile int length; __asm ldw x, #l_RAM_CODE ldw (0x01, sp), x __endasm; return length; }

[bugs:#2421] STM8 code in RAM

Status: closed-fixed
Labels: RAM STM8
Created: Fri Sep 25, 2015 10:46 PM UTC by gicking
Last Updated: Tue Sep 29, 2015 07:18 PM UTC
Owner: Ben Shi


STM8 flash w/e block operations have to be executed from RAM. However, when compiling any source file with option --codeseg MYSEG I get this message:

sdcc -mstm8 --std-sdcc99 -DSTM8S207 --codeseg MYSEG -c RAM_routines.c -o RAM_routines.rel RAM_routines.asm:96: Error: <u> undefined symbol encountered during assembly removing RAM_routines.rel make: *** [RAM_routines.rel] Error 1

The respective error line in file RAM_routines.asm reads
.area MYSEG (CODE)

Attached please find an example which toggles GPIO from RAM (just type "make"). Execution from flash works.

The error occurs under MacOSX and Win7, and sdcc -v yields

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.5.0 #9253 (Jun 20 2015) (Mac OS X i386)
published under GNU General Public License (GPL)

initial response by Maarten:

It seems it outputs an extra (CODE) piece that should only be used on Harvard architectures (e.g. mcs51).

Sent from because you indicated interest in

Please do not reply to this message. Post your messages on the original page

To unsubscribe from further messages, please visit

Sdcc-user mailing list
Vaclav Peroutka | 1 Oct 07:30 2015

sdasZ80 and undocumented instructions

Hello all,

I got some old Z80 assembler source code and tried to compile it with SDCC's assembler.

But I got errors:

mumak47.20141226.asm:249: Error: <o> .org in REL area or directive / mnemonic error
mumak47.20141226.asm:262: Error: <o> .org in REL area or directive / mnemonic error
mumak47.20141226.asm:262: Error: <q> missing or improper operators, terminators, or delimiters

On those lines, there are SLS D and SLL D instructions.

Do I have to enable them in sdasz80 somehow or they are just unsupported ? Can somebody add them ?


Sdcc-user mailing list
Victor Munoz | 28 Sep 06:48 2015

Handling of internal EEPROM for mc51

Hello Maarten,

I'm sorry for my rudeness, I hit the wrong button and my message got sent before I wanted.

I was about to write an example of what I meant:

    struct MOTOR_CONFIG {
          uint8_t item1; // 8 bits EEPROM item
          uint16_t item2; // 16 bits EEPROM item
          uint32_t item3; // 32 bits EEPROM item
          uint8_t reserved_bytes [10];  // Array EEPROM item

    struct MOTOR_DATA {
          uint8_t item1; 
          uint16_t item2;
          uint32_t item3;

      __eeprom MOTOR_CONFIG motor1;   // This data is mapped in the EEPROM
      __eeprom MOTOR_CONFIG motor2;   // This data is mapped in the EEPROM
      __xdata MOTOR_DATA motor1;          // This goes into the XDATA
      __xdata MOTOR_DATA motor2;          // This goes into the XDATA

Thank you again for taking the time to read.


Sdcc-user mailing list
Victor Munoz | 27 Sep 07:21 2015

Handling of internal EEPROM for mc51


I have a problem handling the internal EEPROM feature of an Atmel chip. If anyone could show me how this should be handled, I would be grateful.

I have been using an AT89C51ID2 chip that features 2 kbytes on chip EEPROM. The address space of the EEPROM is shared with the on chip expanded ram as follows.

              On chip expanded RAM: Starts at 0x0000 and ends at 0x06FF
              On chip EEPROM: Starts at 0x0000 and ends at 0x7FF

Both must be accessed using XRAM memory space (i.e. use either movx <at> dptr,a or movx a, <at> dptr.) In order to select the EEPROM, the EEE bit (bit 1) of EECON register (0x00D2) must be set.
Up to this point this is straightforward for me; however, in order to handle the EEPROM memory I am defining variables and structures. For example for an structure I define the following:

     struct CONFIG {
           uint8_t     item1;      // 8 bits EEPROM item
           uint16_t   item2;      // 16 bits EEPROM item
           uint32_t   item3;      // 32 bits EEPROM item

 Then I define variables in XDATA memory:

      __xdata CONFIG configuration;
      __xdata uint8_t eeprom_variable;     // Independent EEPROM variable

A set service function take the address of the variable and handles the EEPROM writing and reading:
      void eeprom_write_8 (unsigned int address, uint8_t data);
      void eeprom_write_16 (unsigned int address, uint16_t data);
      void eeprom_write_32 (unsigned int address, uint32_t data);
      uint8_t eeprom_read_8 (unsigned int address);
      uint16_t eeprom_read_16 (unsigned int address);
      uint32_t eeprom_read_32 (unsigned int address);

As you may see, the problem with this approach is that the linker won't have any clue whether any of these variables belong to the EEPROM or the internal extended RAM. As a result, the extended RAM variables will be mixed with the EEPROM variables. A second drawback is that the useful space will be reduced for both devices due to the fact that their memory addresses are overlapped.

In order to pack EEPROM variables in a contiguous space I can define the EEPROM variables in PDATA space. This puts RAM variables just after EEPROM variables but reduces the EEPROM address space to 256 bytes.

The specific questions would be. Is there any way to tell the linker that the address space is shared? is there any possibility to define an additional address space?

I have been looking for an answer online but the closest reference is this:

Thank you for taking the time to read.

Best regards,
Sdcc-user mailing list
Rich Bayless | 24 Sep 16:29 2015

finding conflicting address space usage

Hello SDCC,
I've been using SDCC for programming MCS51 micros.  My program is split up into multiple files, such as main.c/h, then file1.c/h, file2.c/h, etc.
Global variables are declared in the beginning of each .c file.  Then if the global variable is referenced in another .c file, an extern is added in the beginning of the other .c file. 
So when done properly, it would look like this:
file1.c:   __idata char var1 =1;
file2.c:  extern __idata char var1;
So far, so good, and everything works great.
Then later on I'm editing things and change the declarations incorrectly, such as this:
file1.c:   __xdata char var1 =1;
file2.c:  extern __idata char var1;
Notice that file1 says xdata, while file2 says idata.
This compiles and links fine, but doesn't run properly due to mixed up memory accesses.  Then I have to hunt down the error, usually among the last changes made of course.
My question is, is there some tool/flag/setting that will provide a warning about this error?  Something in the linker?
Thanks,  Rich.

Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
Sdcc-user mailing list
Georg Icking-Konert | 15 Sep 17:55 2015

STM8 code in RAM

hallo all,

following up an earlier question (see below) I encounter the following problem: STM8 flash block write & erase operations need to be executed from RAM. I (hope I) correctly followed the below proposal by Klaus and Maarten, as well as the SDCC manual. However, when compiling any source file with option “--codeseg MYSEG“ I get this error message:

sdcc -mstm8 --std-sdcc99 -DSTM8S207 --codeseg MYSEG -c RAM_routines.c -o RAM_routines.rel
RAM_routines.asm:96: Error: <u> undefined symbol encountered during assembly

The respective error line in file RAM_routines.asm reads
.area MYSEG     (CODE)

I have prepared a simple example (toggles GPIO from RAM), which is available under . For any help on this topic thanks a lot in advance!

PS: the SDCC version is 3.5.0, and the error occurs under MacOSX and Win7

Georg Icking-Konert


Message: 2
Date: Sat, 05 Apr 2014 23:09:05 +0200
From: "Maarten Brock" <>
Subject: Re: [Sdcc-user] SDCC/STM8 questions
Message-ID: <>
Content-Type: text/plain; charset=US-ASCII

4) code in RAM: actually I don?t need it for performance but to log
data to the program flash, because the EEPROM is too small for my
needs. To my understanding the program flash of the STM8 doesn?t
support execute-while-write, so I need the actual flash write&erase
routines in RAM?? At least the Cosmic compiler (and STM8 boot
loader) require that. The Cosmic compiler supports that via #pragma
and linker settings. Can this be done in SDCC as well and, if yes,
how? A small example would be highly welcome? ;-)

It should be possible e.g. by having the code that goes into RAM in a
separate file and using the --codeseg option to sdcc and -b option to
the linker.

I don't think this is enough. It will be located and linked at the
destination address. But you probably need a copy in flash that at
startup is copied to ram. So you need to post-process the linked
object (hex-file) to move it. And then you need a routine for making
the copy.


Sdcc-user mailing list
Mathieu Chouinard | 9 Sep 16:57 2015

Rabbit 4000

Is there any plans to support the Rabbit 4000? I'm definitely not impressed with
dynamic C

Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
Hynek Sladky | 4 Sep 14:05 2015

Z80 code in RAM


I need to run assembly code in RAM. Is there any way how to write such source code? I need the compiler to produce "initialization" data in ROM which will contain the code with all addresses calculated for RAM placement, so the code can be a part of initialized data...

Sdcc-user mailing list
Wolle K. | 26 Aug 23:27 2015

Re: How do your interrupt handlers look like

Derived from ST Micro's workaround 2 (CD00237242.pdf, 1.1.3):
Expecting a DIV / DIVW instruction in ISR, you can simply insert
push #0x28
pop cc
at the beginning of interrupt handler.
This is for concurrent interrupt handling only, for nested interrupts, the interruptability level must be encoded:
push #0b00<i1>0<i0>000
pop cc
Advantage: 3 bytes of code, 2 execution cycles
Disadvantage: overrides Software priority register settings.
Sdcc-user mailing list
roelof 't Hooft | 26 Aug 00:34 2015

derna is going offline


I was just notified that derna, the server that compiles
a sdcc windows package, is being taken offline tomorrow.
I am in the process of making a backup of files on the
We hope to restore the server as soon as possible.
(I have to because it runs all our email data things)

I am really sorry for the inconvenience this causes.

Maarten, you can contact me by personal mail.
Damn that is also hosted on derna........
I will contact you if needed from another account.