Mentor

Slava Pestov

Skills required

• Knowledge of compilers
• Knowledge of ARM assembly
• Knowledge of C and Factor
• Tethered development and two-machine debugging

Level

Advanced

Existing work

Factor used to run on ARM, but the port is now unmaintained. Parts of the existing code should be easy to salvage. This includes the ARM support in the VM, and the ARM assembler in Factor. The ARM compiler backend will need to be rewritten because the compiler's architecture has been changed since then.

Technical details

This project will involve four tasks. The first three are highly technical and have pretty equal difficulty. The last one is more holistic and open-ended.

Porting the VM

The VM needs to have support for the ARM architecture. There are several things to do here:

• implementing some primitives in assembly, such as fixnum+. The existing code in vm/cpu-{x86,ppc}.S can be used as a guide.
• implementing signal handling support. This is C code, but CPU-specific since Factor modifies registers in the trap context.

Porting the non-optimizing compiler

The Non-optimizing compiler has a backend for each CPU which defines sub-primitives in assembly. These are static assembly snippets which are concatenated together. The existing backends in basis/cpu/{x86,ppc}/bootstrap.factor can be used as a guide. The new code would go into basis/cpu/arm/bootstrap.factor.

Porting the optimizing compiler

The first two tasks are mandatory in order to get Factor to do anything useful on the ARM. This task is optional, but it is an important part of making Factor usable on ARM. The Optimizing compiler has a backend for each CPU which defines code generator templates for abstract instructions. These are more fine-grained than the non-optimizing compiler's sub-primitives. The code is in basis/cpu/{x86,ppc}/ can be used as a guide. The new code would go into basis/cpu/arm/arm.factor.

Optimizing space usage and performance

Since embedded systems have less memory and CPU resources than desktops or servers, performance is critical. Part of the project would involve identifying parts of Factor which are responsible for the biggest space and time overheads and improving the algorithms and implementation of the code to minimize this.

Validation

The project will be deemed to be complete when all core unit tests pass (running test-all in a freshly-bootstrapped image). Additionally, some level of performance analysis will be required to ensure that the resulting ARM port is performant enough to be used for real applications.

Benefit to the student

The student will gain experience in porting a real-world compiler to a new CPU architecture.

Benefit to the community

Factor will be usable for a wider range of projects if it can run on embedded ARM systems.

Challenges

• Developing code to run on an embedded system is more difficult than on a desktop system, since development and testing are typically done on different machines. The student will need to familiarize themselves with the various tools used for this.
• Factor's memory consumption will need to be reduced. By the time GSoC work begins, we should have a new garbage collector in place, which will help. However the student will also need to do space profiling of the Factor image and identify code where more space-efficient data structures can be used.