[stm8] create section or attribute.

[Hoksmur]

Hi, All.
I potr my small program from COSMIC to SDCC. Standart Peripherial Librarry uses a sections.

void FLASH_ProgramByte(uint32_t Address, uint8_t Data)
{
    /* Check parameters */
    assert_param(IS_FLASH_ADDRESS_OK(Address));
    *(PointerAttr uint8_t*) (uint16_t)Address = Data;
}

Fragment

*(PointerAttr uint8_t*) (uint16_t)Address = Data;

unroll to

*(@near uint8_t*) (uint16_t)Address = Data;

for COSMIC or

*(__near uint8t*) (uint16_t)Address = Data;

for IAR.
How to decide this part? And I'd want describe EEPROM section as a section starts from EEPROM_START adress.

I have read online manual but I still do not have any idea

[Philipp Klaus Krause]

SDCC currently does not support __near on the STM8.
You can just leave it out.
It is unclear if SDCC will add support for __near in the future, since it is not very useful on the STM8
I guess it is in Cosmic mostly because of Cosmic originally being an ST7 compiler with support for the STM8 added in later.

Philipp

[Hoksmur]

Thank you. You are right - I just leaved this one.

Topic closed.

And SPL is not usefull with SDCC - Cosmic drops unused function, SDCC does not. It just deifferent compilers, not more.

[Philipp Klaus Krause]

While I don't use the SPL, someone did port it to SDCC:
https://sourceforge.net/p/sdcc/mailman/message/33450221/
The SDCC linker can drop unused funtions, provided they are in separate modules in a library (works e.g. with the standard library that comes with SDCC).

Philipp

[Hoksmur]

Thank you for the link, I will see.
Philipp, ARM compilers and (I think) COSMIC take a new segment for every function and drop segment(s) if it do not use. If you say how do it in SDCC - I will do it. Now I beliave that better way is something like

/* header */
#define USE_func1 (1)
#define USE_finc2 (1)
#define USE_funcN(0)

/* c-file */
#ifdef USE_funcN
void funcN( type_t args)
{
  // body
}
#endif

[Philipp Klaus Krause]

The SDCC linker basically works like this: Everything from all .rel files is included. From the .lib file, only those modules are included that are necessary to satisfy dependencies on symbols. Thus, unused functions from libraries are not pulled in, unless they happen to be in the same module as a used function. When creating a library from .rel files, one module per .rel file is created (and the compiler before created one .rel file per .c file).

Philipp

[Hoksmur]

Hm.. Interesting.
Then few more question.
1) If a .c-file contents five functions and uses ony one - only this one will used in a output file, right?
2) .h-file conent block #ifdef BL1 #else BL2 #endif ; will .lib-file contents all parts (BL1 and BL2)?
2.1) How you save different code for different memory models x51 MCU?

[Philipp Klaus Krause]

Example: Five files, a.c, l.h, l1.c, l2.c, l3.c. Assume all files include l.h, which has function declarations for all functions. The files l1.c, l2.c, l3.c are compiled into .rel files and linked into a library.
a.c contains functions main(), which calls f1(), and function a().
l1.c contains functions f1() and f4(), which calls f3().
l2.c contains function f2()
l3.c contains function f3()

You compile a.c into a.rel and link it with l.lib. The resulting binary contains everything from a.rel: functions main() and a(). Since main() calls f1(), it also contains everything from the module l1: f1() and f4(). Since f4() calls f3(), it also contains modfule l3 and thus f3(). It does not contain module l2, and thus not f2().

Philipp

[Wolle K.]

Some words about @near in COSMIC compiler. It's called a "space modifier" and in no way outdated.
COSMIC has 3 of them: @tiny, @near and @far.

An object declared as "@tiny" will be placed in the first 256-Byte RAM Page, enabling short addressing modes for assembler, saving code size and, in some situations, execution time. (sdasstm8 doesn't know where objects will be placed after linking, so allways uses long (16-bit) addressing.)

@near places the object in the first 64k of address space, so "long" stm8 addressing modes will be used. That's what sdcc does for all objects (code and data) at present state of development.

@far is for objects that may be placed above 64k-boundary. 24-bit "extended" addressing modes will be used.

I think its the same for IAR, with different keywords.

[Philipp Klaus Krause]

Thanks for the clarification. Apparently, @tiny is what I assumed @near to be.
For stm8 and sdcc, the situation is this: We currently only support 16-bit addressing as default mode, and thus do not need an eplicit equivalent of @near. Other ports, such as mcs51 support different defaults. But currently, IMO, 16-bit addressing seems the only sensible default for the stm8.
8-bit addressing only saves a little bit in code size, and unlike on the st7, does typically not give any speed advantages (the exception would be were code size limits the speed, i.e. execution of code from RAM).
24-bit addressing is horribly slow and complicated, so it does not make a good default. Currently the comiler des not support it, but there will be support for it via __far in the future.
We might also want keywords for 17-bit addressing and for the second 64K of address space.

Philipp