NGI0-Commons-SDCC

NLnet is funding an NGI0 Commons "SDCC" project. NLnet manages NGI0 Commons made possible with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 101135429.

Note: A2a, A2b, C3 in the project plan below, despite being included on this page here for historical reasons, are not part of this NGI0 Commons project. They are part of the NGI0 Core project f8.

Monthly progress reports

June: The MoU is signed, A2a, A2b, C3 were moved over into the f8 project. Work has begun on the new Rabbit ports, __far support for Rabbits, eZ80 and TLCS-90. This also brought a few improvements also relevant to the other z80-related ports. The work happens in the f8l, rabbit and tlcs branches, and is not yet in any state useful to SDCC users.

July: Work continued mostly in the rabbit branch. The compiler-side support for __far looks quite good already. However, for proper testing a bit of work on the assembler will be needed first.

August: At the beginning of the month, the focus was on fixing old bugs in SDCC. IMO, this resulted in [r15614] probably being the most stable SDCC version since the 4.5.0 release. Later there was work in the rabbit branch on generating better code for z80-related ports (in particular for eZ80, TLCS and Rabbits), and on the simulators in trunk, preparing for the future TLCS-870C(1) support.

September: Soon after leaving Brno on the morning after the WG14 meeting there, I (@spth) started working on the C2y stdbit.h bit utilities.. I had estimated an effort of about 10 hours. That would have been plenty of time to write a conforming implementation and corresponding test cases. However, I expect this functionality to become popular among our users, and the users to care about efficiency. So I went with an implementation based on inline functions instead. But the old optimizations for rotations were AST-based and didn't apply to the new inlined stdbit.h rotation functions. So I replaced that optimization by an iCode-based one. Then it turned out that the old AST-based optimization had a bug in the handling of volatile operands, and the different iCode we get now triggered a code generation bug for reads from volatile in the pdk ports. And the new test cases also triggered a few other previously unknown preexisting issues. In the end it all took quite a bit more effort than expected, but SDCC now has very efficient implementations of this new C2y functionality (which, since the functions all use names already reserved in C23, has been made availabale in C23 mode, too).

Later in the month, there was work on rebasing sdas on current upstream asxxxx, and some works towards improving support for atomics in the front-end.

October: Implementation of __dynamicc calling convention support, and rebasing of sdld on current upstream. The atomic branch was merged to trunk (there were no real improvements in real support for atomics yet in that branch, but improved error messages, to now clearly distinguish when something doesn't work due to lack of support in SDCC vs. due to not being allowed by the C standard).

November: An issue in previously merged-to-trunk eZ80/Rabbit support affecting Windows installers was found and fixed directly in trunk. Further work on rebasing sdas on current upstream asxxxx.

December: A bit of work on the TLCS-870(/C) simulator and on TLCS-90 and Rabbit __far support.

January: Further work on the simulators for the TLCS and Rabbit architectures.

February: Further work on the simulator and assembler for the Rabbits. Rabbit 4000-specific instructions have been enabled in the r4k port, and it works well in the simulator. However, we are encountering issues on real Rabbit 4000 hardware that we need to track down so the r4k port can become become stable for the SDCC 4.6.0 release. Towards the end of the month there was also work on merging new upstream versions into SDCC's binutils and cpp forks.

March: Most work was on the Rabbit 4000 support, in assembler, simulator, compiler; this included debugging a Rabbit hardware issue affecting an undocumented instruction mode. In addition current upstream GNU binutils was merged into the SDCC fork; towards the end of the month, most work was on Rabbit __far support to be able to use a 1MB address space for data in the Rabbit ports. There also were various bugfixes throughout the month, in particular for the f8(l) port.

Project Plan

The Small Device C Compiler is the free (apart from GCC having an AVR port) compiler for 8-bit microcontrollers (µC). It is competing with various non-free compilers. 8-bit µC are common in peripheral devices of larger systems, SDCC is an essential part of the free software ecosystem, in particular for developing firmware. We aim to both improve SDCC support for various target hardware, as well as implement machine-independent improvements to make SDCC more competitive vs. non-free compilers. Hardware-specific improvements planned include improving support for Padauk's popular low-cost microcontrollers, improving support for the Rabbit microcontrollers common in older IoT devices, improving code generation for the f8 port, and improving support for Toshiba TLCS microcontrollers. The focus for machine-independent improvements will be in enhancing support for recent ISO C standards, an optimization to reduce memory usage for local variables, and implementing a link-time optimization to optimize out unused functions and objects. The latter is the one feature most-requested by SDCC users in recent years.

A Machine-independent optimization

A1 Efficient allocation of spilt local variables into non-stack memory

Some of the target architectures (mcs51, pdk13, pdk14, pdk15, hc08, s08, mos6502) supported by SDCC do not have efficient access to the stack. For these, by default, SDCC will place local variables at fixed locations in memory. This makes the affected functions non-reentrant, and is thus not compliant with the C standard, but it is common practice for C compilers targeting such architectures. However, in this case, SDCC currently does not use information on the live-ranges to efficiently overlay variables that are not in use at the same time. This results in increased memory usage of the compiled programs, which is particularly problematic for targets devices with little memory. In particular for pdk13 and pdk14 this also currently severely limits regression test coverage, since many tests would need more memory that the target architecture can offer.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Efficient allocation of spilt local variables into non-stack memory (using Chaitin's graph coloring heuristic)	Janko or Philipp?
b.	Enable further regression testing, in particular for pdk13, pdk14	Janko or Philipp?

A2 Link-time elimination of unused functions and objects.

Currently, SDCC compiles source files into modules, from which libraries can be created. The linker will link all modules given to it, and whatever is needed from the libraries to satisfy dependencies. This happens at the module level, i.e. each module is either fully included or not at all. In recent years, having more fine-grained control to remove individual functions and objects was the single feature most requested by users. Some people are not willing to have one source file per function in their libraries. Others have to deal with third-party code that has multiple functions per file. Then there is the use-case of static (inline) functions where all uses are inlined, or initialized const objects where all uses of the object are replaced by the initialization value by optimizations. Identical string literals are allowed to be the same object by C, but SDCC currently only uses this for optimization to eliminate redundant string literals within a translation unit; there is further optimization potential at link time. Before adding new features to the linker, current upstream changes should be merged into the SDCC fork.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Merge aslink from current upstream asxxxx 5.50 into the sdas fork used by SDCC	Janko?		@janko-5
b.	Merge parts of upstream asxxxx 5.50 Update 2 assemblers into the sdas fork used by SDCC	Janko?		@janko-5
c.	Link-time elimination of unused functions and objects	Janko and Philipp?
d.	Link-time elimination of redundant string literals	Janko or Philipp?
e.	Link-time sharing of partial storage of string literals and constant compound literals	Janko or Philipp?

B Standard compliance and reliability

B0 Reliability

About half of the SDCC users use it on the Windows OS. Virtually all development happens on GNU/Linux. This results in Windows-specific issues typically being found late, and not fixed quickly. SDCC does not currently use measures to prevent DLL side-loading attacks on Windows. SDCC has a large regression test suite, built from artificail test cases, rproducers for fixed bugs, and adopted tests from other sources. Among hte latter, GCC is the most important. We should adopt the tests that GCC added in recent years (tests need to be reviewed for their auitability for SDCC and SDCC targets). Over time, SDCC has accumulated quite a number of open bug reports. While most bug reports get dealt with quickly, bugs that are harder to track down and fix sometimes stay around and accumulate. For a compiler, where bugs can affect even indirect users (i.e. users of programs compiled with SDCC), open bug reports are quite worrying. Bug reports need to be tracked down, verified and fixed. This is divided into bug sprints of (at least) 20 hours each addressing SDCC bugs reported before the start of this project.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Specify Windows DLL paths via manifests in SDCC executables, so SDCC does not use unsuitable DLLs from the $PATH, and other applications don't use SDCC's DLLs from the $PATH	Janko?		@janko-5
b.	Adopt recently-added GCC tests	Felix and Philipp?
c.	Bug Sprint	Janko or Philipp or Benedikt or Felix?
d.	Bug Sprint	Janko or Philipp or Benedikt or Felix?
e.	Bug Sprint	Janko or Philipp or Benedikt or Felix?
f.	Bug Sprint	Philipp or Benedikt or Felix?	[bugs:#3809] [bugs:#3855] [bugs:#3850] [bugs:#3281] [bugs:#3737] [bugs:#3176] [bugs:#3718] [bugs:#3719] [bugs:#3852] [bugs:#3823] [bugs:#3854] [bugs:#3355] [bugs:#3278] [bugs:#2725] [bugs:#2746] [bugs:#3668] [patches:#460] [patches:#363] [patches:#470] [patches:#429] [patches:#394]	@spth (DONE)
g.	Bug Sprint	Janko or Philipp or Benedikt or Felix?		@spth
h.	Bug Sprint	Janko or Philipp or Benedikt or Felix?
i.	Bug Sprint	Janko or Philipp or Benedikt or Felix?
j.	Merge latest binutils release into SDCC fork	Philipp or Felix?	[feature-requests:#962]	@spth

B1 ISO C99 compliance

SDCC currently supports most versions of the C programming language standard to a very large degree, but even for the oldest versions, ISO C90 / ANSI C89, ISO C94 and ISO C 99, there are a few remaining gaps, that should be filled. In the backends, the ds390, hc08, s08, mos6502, mos65c02 ports currently do not support returning struct / union, or only up to a small size. Basically just port the support already implemented in other ports. For ds390, it should be relatively easy to port support from the mcs51 port. Once support for either hc08 and s08 or mos6502 and mos65c02 is implemented, it should be relatively easy to port it to the other. The support for a higher number of significant characters in identifiers with universal character names will require work in all of compiler, assembler and linker. Full support for double and long double would require a suitable support library. All the rest would be work on the compiler front-end.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Full struct / union return support for ds390	Janko?
b.	Full struct / union return support for two ports out of hc08, s08, mos6502, mos65c02	Janko?	[feature-requests:#879]
c.	Full struct / union return support for the remaining two ports out of hc08, s08, mos6502, mos65c02	Janko?
d.	Support flat initializer lists for nested array types, i.e. the omission of inner braces, and implement new semantics for anonymous struct / union	Benedikt?	[feature-requests:#562]
e.	Treat float, double and long double as distinct types in SDCC	Benedikt?
f.	Integrate an ISO C compliant floating point library	Benedikt?
g.	Fully support prototype-less functions	Benedikt?
h.	Support the required number of significant characters in internal identifiers with universal character names	Benedikt and Janko?

B2 ISO C23 compliance

SDCC mostly support the latest programming language standard, ISO C23, but support is not yet as complete as for the earlier ISO C11 / ISO C17.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Improve the efficiency of checked integer arithmetic	Benedikt and Philipp?
b.	Adapt the semantics of _Generic to recently resolved ambiguities in the standard	Benedikt?		@roybaer (DONE)
c.	Qualifier-preserving macros for standard library functions	Benedikt?	[feature-requests:#848]	@roybaer (DONE)
d.	Support constexpr named constant expressions	Benedikt?	[feature-requests:#850] [bugs:#3837]	@roybaer (mostly done)
e.	Find and implement remedies for LALR(1) parser conflicts preventing full attribute support	Benedikt?	[feature-requests:#654]
f.	Optimizations based on standard attributes	Philipp?
g.	Merge current cpp (from GCC 15) into the sdcpp fork to get ISO C 23 #embed support, and __has_attribute or replace the preprocessor by an alternative (e.g. based on boost.Wave or ucpp)	Felix or Benedikt?
h.	Replace current calling convention selection keywords by a syntax based on C23 attributes	Philipp?

B3 Possible future C2Y compliance

There is ongoing work towards the future C2Y standard. SDCC should try to keep up with this, especially where relevant to small systems, despite some risk of possible changes between current C2Y standard drafts and the final standard.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	C2Y bit utilities support	Philipp?	[feature-requests:#1000] [bugs:#3874]	@spth (DONE)
b.	C2Y restartable functions for efficient character conversions	Philipp?
c.	C2Y size_t suffix	Benedikt or Philipp?		@roybaer (DONE)
d.	C2Y containerof	Benedikt or Philipp?		@roybaer (DONE)
e.	C2Y likely if declaration changes	Benedikt?	[feature-requests:#979]
f.	C2Y likely defer	Benedikt and Philipp?
g.	C2Y anonymous struct / union initialization semantics	Benedikt?

B4 Debugging support

Currently, debug information emitted by SDCC tends to be somewhat inaccurate, in particular wrt. inlined functions and local variables allocated to the same memory location (which currently only happens for architectures with efficient stack access, but will become more common when the "Efficient allocation of spilt local variables into non-stack memory" is implemented). Also, apparently, the DWARF info emitted by SDCC is not fully up to the DWARF standard, and SDCC currently can emit DWARF debug info for some targets only, while for the others, debug information using the older CDB standard is supported only. Also support for DWARF is currently limited to the older DWARF 2. All these issues make debugging a program compiled with SDCC a less user-friendly experience than one compiled with e.g. GCC. The uCsim simulator has its own command line user interface, and can be used with the SDCDB debugger (which supports the CDB debug info format that all SDCC ports can emit); but GDB is substantially more powerful in many ways, and many IDEs can interact with it, so it would be great, if GDB could be used with the uCsim simulators.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Fix debug information for inlined functions	Janko?
b.	Emit proper debug information of live-ranges of local variables	Janko?
c.	Enable output of ELF/DWARF for more targets (might require some coordination with GNU binutils on register numbers for these targets)	Janko?
d.	Make DWARF output use the recent DWARF 4 standard	Janko?
e.	gdbserver protocol for uCsim	Janko or Daniel?	[feature-requests:#966]

B5 Atomics

The only atomic types currently supported by SDCC are atomic_flag and volatile sig_atomic_t only. Though in a previous NGI0 project on improving atomic_flag support, we were able to already implement support for further atomic types in the mcs51 backend via restartable sequences. We want to implement support for the atomic qualifier in the front-end. This could then be translated into calls to atomic_compare_exchange loop implementations at high level (or passed through to the back-end if the back-end has support for the specific atomic operation). atomic_compare_exchange would be implemented as restartable sequence (works for single hardware thread only) in the backends, as it already is for mcs51. How easy this is depend on the port. E.g. a flat address space will help vs. the MCS-51, but a lack of addressing modes in atomic write instructions would require the use self-modifying code.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Support the atomic qualifier in the front-end, and implement support for atomic operations via transformation to atomic_compare_exchange calls early	Philipp?		@spth
b.	Support for atomic_exchange and atomic_compare_exchange via restartable sequences for one more port family	Philipp or Janko?
c.	Support for atomic_exchange and atomic_compare_exchange via restartable sequences for one more port family	Philipp or Janko?
d.	Keep the atomic operations, and handle them correctly throughout compiler stages, to only convert to atomic_compare_exchange calls before handing the intermediate code over to the backend	Philipp?
e.	A mechanism to announce support for individual atomic operations by ports, and implement such operations in one port	Philipp?
f.	Atomic operations in one more port family	Philipp?
g.	Atomic operations in one more port family	Philipp?

C Hardware support

C0 Padauk support

The Chinese company Padauk sells extremely low-cost µC (average price below 1¢ per SoC) in huge amounts. We currently have pdk13, pdk14, pdk15 ports, for the low-end Padauk µC in SDCC. pdk16 is the only pdk subarchitecture we currently don't support at all. The pdk16 will be similar to the existing ones, as long as we only support code generation for 1 core (as we do for the other pdk ports). One notable difference to pdk13, pdk14, pdk15 that will affect code generation is that pdk16 supports up to 512B of RAM, and thus pointers to RAM need to be wider than an 8-bit byte. Also, pdk15 has instructions to read both the lower and upper byte of a 16-bit word in ROM, so to make efficient use of ROM for constants, we want to use that (while pdk13, pdk14, pdk15 for constants only use the lower 8 bits of each word in ROM, which for these ports is less than 16 bits wide). easypdkprog is the free tool (consisting of both hardware, firmware and software) to write the program memory of Padauk µC. Supporting a device in it requires reverse-engineering the protocol used by the non-free tools from Padauk, checking if the easypdkprog hardware is capable of replicating the protocol, and if yes, implementing support in the firmware and software. The pdk architectures have some instructions where 16-bit alignment of the operands is required, which apart from very few Rabbit instructions is unique among the archicectures upported by SDCC. SDCC should get the necessary infrastructure to align dfata suiatbly where it makes sense, and pass this information to the back ends, where it can be used by code generation.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Get a basic pdk16 port working, and pass regression tests (still using 8-bit pointers to RAM, one ROM word per constant byte)	Janko or Philipp?
b.	Enable the use of the full 512B of RAM	Janko or Philipp?
c.	Enable the use of both 8-bit bytes in 16-bit ROM words for constant data	Janko or Philipp?
d.	Support more Padauk devices in easypdkprog	Janko, Philipp, Benedikt and Felix?
e.	Implement infrastructure to support 16-bit alignment of variables (by default, where reasonable as determined by a heuristic, and via ISO C23 _Alignas by explicit user choice), and use it in the Padauk and Rabbit backends	Janko and Philipp?	[feature-requests:#604]

C1 Rabbit and eZ80 support

The Rabbits are an older series of microcontrollers once common in IoT devices. There are multiple sub-variants, most important the Rabbit 2000, 2000A, 3000A, 4000, 5000 and 6000. While they are still in production, the only current manufacturer has announced that they will be discontinued. While they are not used much in the development of new devices recently, having support for them in a free compiler is still useful when working on firmware for existing devices, especially if the current development environment from the manufacturer becomes unavailable. SDCC currently has ports for the Rabbit 2000, 2000A and 3000A. However, the code generated just uses a 64 KB address space, while Rabbit-based devices typically have more memory (up to 1 MB for Rabbits up to 3000A, up to 16 MB for Rabbit 4000 and above). By implementing a memory model that uses the Rabbit XPC register, we can support the use of the full 1 MB address space for code (but not data, for that we'll need __far, see below), substantially improving the usefulness of SDCC for the Rabbits. We also want to make use of some of the improved 16-bit and 32-bit support that first appeared in the Rabbit 4000, by introducing a port for the Rabbit 4000. From a compiler perspective, the Rabbit 5000 is very similar to the Rabbit 4000, but a few instructions have different timing, and there is a hardware bug affecting the ret cc instruction that requires a workaround, so it needs to have its own port. To be able to use more data memory, we want to introduce support for larger data pointers via a __far named address space. To call into hand-written assembler code originally written for the Dynamic C compiler, we want to introduce basic support for its calling convention. OpenRabbit is a free tool to write the flash memory of the Rabbit microcontrollers. Unfortunately, it has some limitations (incomplete Rabbit 4000 support, no Rabbit 5000, 6000 support), and reliability issues. To prepare for a r6k port in SDCC, and to allow users to use Rabbit 6000 assembler code with SDCC Rabbit ports, the Rabbit 6000 instruction set should be supported in the assembler and the uCsim simulator. The Rabbits have two separate i/o spaces - internal and external. Currently, SDCC supports the internal one only. The Rabbit and eZ80 hardware also supports pointers into i/o space, which is currently not supported by SDCC. Like the Rabbits, the Zilog eZ80 is modern Z80 derivative used in IoT devices; it is made by Zilog, and still recommended for development of new devices. Again the code generated by SDCC is limited to a 64 KB address space, while tha hardware supports a bigger addres space. This is less of a problem for eZ80 than for the Rabbits: SDCC uses the eZ80 in Z80 mode (16 bit), which has the 64 KB limitation, but has faster and smaller code. The eZ80 also has ADL mode (24 bit), with an flat 16 MB address space supported by a LLVM port. Still, for some applications, it would be useful to be able to have a Z80 mode program that can also use some data beyond the 64 KB address space. This could be done by implementing a __far address space that uses individual ADL mode instructions within a program otherwise using Z80 mode, which will also require changes in startup code and interrupt handling due to the quirks of mixing Z80 mode with ADL mode code. Currently, code generation in the Rabbit and eZ80 port handles direct operands (i.e. operands in the 64K address space with addresses known at link time) by pointing the iy register, and if there is another such operand, the hl register to it. This is a rather crude heuristic that predates the rest of code generation and the current register allocator, often resulting in suboptimal code for operations involving global operands. A better heuristic would take into account the size of operands, and the register allocation. Implementing this will also require some changes in code generation.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Full support for the Rabbit 4000 instructions in the assembler	Janko?	[feature-requests:#970] [feature-requests:#714] [feature-requests:#983]	@janko-5
b.	Support for the Rabbit 6000 instructions in the assembler	Janko?	[feature-requests:#970] [feature-requests:#714] [feature-requests:#983]	@janko-5
c.	New r4k port to better support the Rabbit 4000 making use of some of the new instructions added in the Rabbit 4000	Philipp?	[feature-requests:#956]	@spth (DONE)
d.	New r5k port for the Rabbit 5000 (based on the r4k port with adjustments for changes in instruction timing and hardware errata)	Philipp?	[feature-requests:#961]	@spth
e.	Use the JK register introduced in the Rabbit 4000 in the new r4k port, by implementing support for it in register allocation and code generation	Philipp?
f.	Rabbit __far intrinsic named address space to allow use of 20-bit addresses for data (via ldp instructions, and ldf on Rabbit 4000)	Philipp?	[feature-requests:#981]	@spth
g.	A memory model that makes the Rabbit 1 MB address space usable for code. Similarly to the large memory model in the SDCC stm8 port, function pointers would become wider than object pointers	Janko and Philipp?	[feature-requests:#995] [feature-requests:#980]	@spth
h.	Based on the previous, a memory model that makes the Rabbit 4000 and later 16 MB address space usable for code	Janko and Philipp?	[feature-requests:#995]	@spth
i.	Basic support for a __dynamicc calling convention for interaction with assembler code written for Dynamic C	Philipp?	[feature-requests:#965]	@spth (DONE)
j.	Improve basic OpenRabbit functionality: Support for larger than 1 MB address space, 16-bit wide memories, serial flash, Rabbit 5000, Rabbit 6000	Janko or Philipp?
k.	On-target debugging support via gdbserver protocol in OpenRabbit or an alternative	Janko?
l.	Basic Rabbit peripheral (GPCU, PREV, timers A, B and C, real-time clock, interrupt controller) support in uCsim	Janko or Daniel?
m.	Rabbit 6000 support in uCsim	Janko or Daniel?	[feature-requests:#955] [feature-requests:#994]	@drdani
n.	New r6k port for the Rabbit 6000 (based on the r5k port, making use of some instructions added in the Rabbit 6000)	Philipp?	[feature-requests:#997]	@spth
o.	Support for stack protection safety feature of Rabbit 3000A and later	Philipp?	[feature-requests:#975]
p.	Support Rabbit external i/o named address space	Philipp or Janko?	[feature-requests:#752]
q.	Support pointers to Rabbit and eZ80 i/o address spaces	Philipp or Janko?
r.	eZ80 __far intrinsic named address space to allow use of 24-bit addresses for data (via ADL mode instructions)	Philipp?	[feature-requests:#982]	@spth
s.	Heuristic for access to direct operands for Rabbit and eZ80 ports, and adapt code generation accordingly	Philipp?		@spth

C2 TLCS support

The Toshiba TLCS-870/C1 and TLCS-870/C1E are modern, still recommneded for new devices, derivatives of the TLCS-90 (via TLCS-870 and TLCS-870/C), itself a Z80 derivative. SDCC currently only supports its ancestor TLCS-90. We want to improve TLCS-90 support, add TLCS-870, TLCS-870/C and TLCS-870/C1(E) support. By itself, it would not be worth putting much effort into the ancient TLCS-90 and TLCS-870, since only few devices containing them are still in use today. However, these are important stepping stones on the way towards getting to TLCS-870/C(1,1E) support, and going directly for TLCS-870/C(1,1E) support instead wouldn't reduce the total amount of work much.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	TLCS-90 __far intrinsic named address space to allow use of 20-bit addresses for data via BX and BY registers	Philipp?		@spth
b.	TLCS-90 cost function for better code size optimization	Philipp?	[feature-requests:#996]	@spth (DONE)
c.	Assembler support for TLCS-870	Janko?
d.	Assembler support for TLCS-870/C and TLCS-870/C1	Janko?
e.	TLCS-870 uCsim support	Janko or Daniel?
f.	TLCS-870/C and TLCS-870/C1 uCsim support	Janko or Daniel?		@drdani
g.	New tlcs870 port for the TLCS-870	Philipp and Janko?	[feature-requests:#999]
h.	New tlcs870c port for the TLCS-870/C	Philipp and Janko ?	[feature-requests:#998]	@spth
i.	New tlcs870c1 port for the TLCS-870/C1 and TLCS-870/C1E, (based on tlcs870c port)	Philipp?	[feature-requests:#998]	@spth
j.	Free flash tool using the ROM bootloader for Toshiba TLCS-870/C1 and TLCS-870/C1E	Janko?

C3 f8l port

The f8l is a simplified variant of the f8; an f8l core needs about half as much space (die/gate count) as an f8. This variant of the f8 should be supported by SDCC. Since the f8l instruction set is a subset of f8, initial regression testing can be done using the f8 support in uCsim, but to ensure that no f8-specific opcodes end up in binaries produced by the f8l port, it would be better to have real f8l support in uCsim.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	f8l assembler support	Janko?
b.	f8l uCsim port	Philipp or Janko or Daniel?
c.	f8l SDCC port	Philipp?		@spth
d.	Basic f8/f8l peripherals (timer, watchdog, interrupt controller, gpio) support in uCsim	Philipp or Janko or Daniel?

C4 S08 support

The NXP S08 is a current microcontroller family supported by SDCC. Some of the larger devices have a flash memory so large that it does not fit into the flat 64K address space. By implementing a memory model that uses the S08 ppage register, we can support the use of the full address space for code.

Milestone	Description	Suggested devs	Tickets	Devs working on it
a.	Support complex symbol expressions, and S08 call and rtc instructions, in assembler and linker	Janko?
b.	Support discontinuous areas in linker	Janko?
c.	Support S08 ppage, call and rtc in uCsim	Janko or Daniel?
d.	A memory model that makes the S08 128KB address space usable for code. Similarly to the large memory model in the SDCC stm8 port, function pointers would become wider than object pointers	Philipp or Janko?