Project ideas
Project Ideas (for GSoc, bachelor projects, etc):
SDCC is a C Compiler, mostly written in C. Some knowledge of C is essential for working on any of these projects. In some places, a bit of C++, Python, Makefiles, autoconf / autotools, m4 is used; some knowledge of these can be helpful, is not required.
pdk16 support tools
Implement pdk16 support in assembler, simulator (pdk16 has hardware multihreading, making this simulator in some way more interesting than the exisiting ones). pdk16 is the last remaining pdk subarchitecture not yet supported by SDCC.
Some relevant tickets:
Improve standard compliance
In particular passing, returning struct and union, improve attribute support, compound literals). See also [Standard Compliance].
Some relevant tickets:
- https://sourceforge.net/p/sdcc/feature-requests/332/
- https://sourceforge.net/p/sdcc/feature-requests/450/
- https://sourceforge.net/p/sdcc/feature-requests/654/
Merge the sdas fork of asxxxx 3 with current upstream asxxxx 5.
SDCC uses a fork of the asxxxx 3 assembler/linker suite. Due to license incompabilities, a merge was not possible for a while. Now asxxxx 5 is licensed unter GPL3, there is no legal issue any more, but sdas and asxxxx have diverged quite a bit over time.
Revive and improve the LLVM+SDCC toolchain.
There is a (old) web page on the LLVM+SDCC toolchain: http://www.colecovision.eu/llvm+sdcc/. The basic idea of LLVM+SDCC is to use the LLVM C backend (dropped from LLVM long ago, but sometimes maintained and updated in GitHub repos outside of the LLVM project).
One could start by porting this to a newer LLVM version (probably first to LLVM 8, as the C backend has already been ported to LLVM 8, then maybe further by also porting the C backend to newer LLVM), looking into bugs and inefficiencies affecting LLVM+SDCC.
Translating LLVM IR to SDCC iCode could be an alternative, but it probably far more work, both when implementing it and when maintaining it (LLVM IR tends to change).
Implement link-time elimination of unused objects / functions.
This is both an often-requested feature in itself, and also one way to avoid the code-size increase LLVM+SDCC currently gives over plain SDCC.
Historically, people used one .c file per function for libraries, and did not have unused functions in their application code. This has changed, and multiple functions per source file, with some of them unused is now common. Still, users expect compilers to optimize out the unused stuff. GCC has -ffunction-sections, but SDCC still creates one module per source file, and the linker pulls in whole modules.
Some relevant tickets:
- https://sourceforge.net/p/sdcc/feature-requests/150/
- https://sourceforge.net/p/sdcc/feature-requests/452/
- https://sourceforge.net/p/sdcc/feature-requests/413/
Implement two-pass processing of source, allowing compile-time elimination of unused static objects / functions.
This is both an often-requested feature in itself, and also one way to avoid the code-size increase LLVM+SDCC currently gives over plain SDCC.
Some relevant tickets:
Improve the mcs51 backend
The mcs51 backend was the first bakend in SDCC. However, over the years, it has fallend behind a bit, and the generated code does not compare well to what non-free compilers generate for MCS-51. This should at least include porting the Chaitin-style stack allocator to mcs51, and the implementation of the notUsed() and notUsedFrom() peephole helper functions and suitable peephole optimizer rules.
Some relevant tickets:
Port tree-decomposition-based register allocator to mcs51 backend
The use of the new tree-decomposition-based register allocator has substantially helped the z80, hc08 and s08 backends to generate better code. Newer backends use it exclusively. It would be interesting, if we can get a similar improvement in the mcs51 backend. Some basic knowledge of graph theory would definitely be helpful when working on this project. Will also require work in the code generator, and thus a willingness to learn MCS-51 assembler. For the theoretical foundation see Philipp Klaus Krause: "Optimal Register Allocation in Polynomial Time", CC 2013.
A modern preprocessor
Ihe current SDCC preprocessor is a fork of an old GNU preprocessor, 4.6.3. To be ready for modern requirements, such as upcoming C2X, it would be good to have a preprocessor, e.g. by merging the few additional features SDCC requires into a current GCC preprocessor to use for SDCC.
double
SDCC currently support float only, using an IEEE-like format that is not fully IEEE-complaint though. There is no double or long double. Ideally, SDCC should also have a type for "short float" (not yet in the C standard, but there are proposals).
One option could be the use of Berkeley SoftFloat library. Even when it works, it would require careful empirical evaulation to avoid speed regressions. Possibly, some optimizations that help Berkeley SoftFloat would also be wanted in SDCC.
Another option could be to come up with an efficient, non-IEEE type that still fulfills the requirements of the C standard (e.g. a 48-bit double is allowed by the C standard). This would probably require some background in numerics.
Documentation improvement usability glue stuff
The SDCC manul and documentation has mostly been written on-the-go by SDCC developers; sometimes outdated bits haven't been cleaned up in time until years later. Many SDCC users use Windows, while developers mostly use GNU/Linux. Many SDCC users use it from an IDE, but most developers don't.
This has resulted in a less-than-optimal state of documentation for many users.
This could include finding usability / documentation issues e.g. by cognitive walkthroughs and fixing the issues found, looking into support of SDCC in IDEs and posibly updating the support (e.g. Code::Blocks has relatively up-to-date support of SDCC, but could still be improved, while the SDCC Eclipse plugin is unmaintained, and apparenly doesn't work for many users).
PIC improvement (probably not for GSoc)
The Microchip PIC devices are still popular. SDCC has had "in-development" backends for them for quite a while, but they never became stable. Also, the backends depend on mostly unmaintained upstream gputils. There are many possible improvements, that could bring the pic14 and pic16 backends closer to being stable. This requires some knowledge of the PIC devices. It probably wouldn't be a good GSoC project, since we don't have a mentor familiar with PIC.
Related
