Difference between revisions of "LDC project ideas"
(Add new page) |
m (Better formatting.) |
||
Line 5: | Line 5: | ||
== Support a new platform == | == Support a new platform == | ||
− | * SPARC (Solaris/Linux) [Beginner] | + | * SPARC (Solaris/Linux) [Beginner]<br/>LDC already supports Solaris and Linux on x86. A code generator for SPARC is part of LLVM core distribution. Adding support for SPARC is therefore only a matter of adding the missing pieces to druntime and phobos. At least you need to change core.thread, core.stdc.stdarg and std.math. It might also be necessary to introduce a new ABI class to LDC. |
− | LDC already supports Solaris and Linux on x86. A code generator | ||
− | |||
− | At least you need to change core.thread, core.stdc.stdarg and std.math. It might also be necessary to | ||
− | introduce a new ABI class to LDC. | ||
− | * Win32 [Intermediate] | + | * Win32 [Intermediate]<br/>LDC has support for Win64. LLVM 3.7 adds structured exception handling for Windows 32 bit. The exception handling infrasturcture (code generation and druntime support) has to be adapted to this new approach. In addition, druntime and phobos support must be verified and possible extended. |
− | LDC has support for Win64. LLVM 3.7 adds structured exception handling for Windows 32 bit. The exception | ||
− | handling infrasturcture (code generation and druntime support) has to be adapted to this new approach. | ||
− | In addition, druntime and phobos support must be verified and possible extended. | ||
− | * Compile D code as CUDA kernel [Expert] | + | * Compile D code as CUDA kernel [Expert]<br/>LLVM has a code generator for nvptx. The idea is to mark kernel functions with attribute @kernel. During a host compile, a function marked with @kernel requires special care. The function body is not codegened. Instead, a call to this function needs to transfer control to the kernel function. During a kernel compile, only the functions marked with @kernel are considered. There may be better approaches to integrate kernel functions. In addition, the environment has to be considered. E.g. a kernel function cannot use dynamic memory or output something using printf(). |
− | LLVM has a code generator for nvptx. The idea is to mark kernel functions with attribute @kernel. During a | ||
− | host compile, a function marked with @kernel requires special care. The function body is not codegened. | ||
− | Instead, a call to this function needs to transfer control to the kernel function. During a kernel compile, | ||
− | only the functions marked with @kernel are considered. | ||
− | There may be better approaches to integrate kernel functions. In addition, the environment has to be considered. | ||
− | E.g. a kernel function cannot use dynamic memory or output something using printf(). | ||
− | * Support for AIX [Expert] | + | * Support for AIX [Expert]<br/>LLVM generates code for PowerPC CPUs but has no support for AIX. The first step is therefore to output assembler which the AIX assembler can read. This is not too complicated. In addition, the calling conventions has to be checked. The second step (not needed in our case) would be to support the XCOFF binary format. As soon as LLVM can generate code fo AIX, the necessary runtime support needs to be added to druntime and phobos. (I already have some system headers translated.) LDC itself knows about AIX but this support is completely untested. |
− | LLVM generates code for PowerPC CPUs but has no support for AIX. The first step is therefore to output assembler | ||
− | which the AIX assembler can read. This is not too complicated. In addition, the calling conventions has to be checked. | ||
− | The second step (not needed in our case) would be to support the XCOFF binary format. | ||
− | As soon as LLVM can generate code fo AIX, the necessary runtime support needs to be added to druntime and phobos. | ||
− | (I already have some system headers translated.) LDC itself knows about AIX but this support is completely untested. | ||
== Adding new features == | == Adding new features == | ||
− | * Add support for the LLVM profiling instrumentation [Intermediate] | + | * Add support for the LLVM profiling instrumentation [Intermediate]<br/>LLVM offers support for profiling and coverage instrumentation. Add code to support these instrumentations. Write D tools to analyze the generated data. |
− | LLVM offers support for profiling and coverage instrumentation. Add code to support these instrumentations. | ||
− | Write D tools to analyze the generated data. | ||
== Improve existing code == | == Improve existing code == | ||
− | * Reduce memory consumption and improve performance of LDC [Intermediate/Export] | + | * Reduce memory consumption and improve performance of LDC [Intermediate/Export]<br/>LDC is slow compared to DMD. Use profiling to identify performance and memory allocation hotspots and then propose pull requests to fix these hotspots. |
− | LDC is slow compared to DMD. Use profiling to identify performance and memory allocation hotspots and | ||
− | then propose pull requests to fix these hotspots. | ||
== Move source code to D == | == Move source code to D == |
Revision as of 10:41, 2 June 2015
Contents
LDC Project ideas
You like LDC and want to contribute? Here is a collection of ideas you can use as a starting point.
Support a new platform
- SPARC (Solaris/Linux) [Beginner]
LDC already supports Solaris and Linux on x86. A code generator for SPARC is part of LLVM core distribution. Adding support for SPARC is therefore only a matter of adding the missing pieces to druntime and phobos. At least you need to change core.thread, core.stdc.stdarg and std.math. It might also be necessary to introduce a new ABI class to LDC.
- Win32 [Intermediate]
LDC has support for Win64. LLVM 3.7 adds structured exception handling for Windows 32 bit. The exception handling infrasturcture (code generation and druntime support) has to be adapted to this new approach. In addition, druntime and phobos support must be verified and possible extended.
- Compile D code as CUDA kernel [Expert]
LLVM has a code generator for nvptx. The idea is to mark kernel functions with attribute @kernel. During a host compile, a function marked with @kernel requires special care. The function body is not codegened. Instead, a call to this function needs to transfer control to the kernel function. During a kernel compile, only the functions marked with @kernel are considered. There may be better approaches to integrate kernel functions. In addition, the environment has to be considered. E.g. a kernel function cannot use dynamic memory or output something using printf().
- Support for AIX [Expert]
LLVM generates code for PowerPC CPUs but has no support for AIX. The first step is therefore to output assembler which the AIX assembler can read. This is not too complicated. In addition, the calling conventions has to be checked. The second step (not needed in our case) would be to support the XCOFF binary format. As soon as LLVM can generate code fo AIX, the necessary runtime support needs to be added to druntime and phobos. (I already have some system headers translated.) LDC itself knows about AIX but this support is completely untested.
Adding new features
- Add support for the LLVM profiling instrumentation [Intermediate]
LLVM offers support for profiling and coverage instrumentation. Add code to support these instrumentations. Write D tools to analyze the generated data.
Improve existing code
- Reduce memory consumption and improve performance of LDC [Intermediate/Export]
LDC is slow compared to DMD. Use profiling to identify performance and memory allocation hotspots and then propose pull requests to fix these hotspots.
Move source code to D
- Create a libconfig clone in D under the LDC license. [Beginner]
- Create a workable binding to the LLVM C++ API. (Note: all available D bindings use the C API which is not usable for LDC.) [Expert]
- Translate ldmd2 to D. [Beginner]
Maintain an LDC package
- Create and maintain a FreeBSD fresh port.
- Create and maintain a Solaris/OpenIndiana IPS port.