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 changed significantly since the last port was completed.

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 two items of work that must be done here. First, updating vm/cpu-arm.hpp with the following:

• Reading and writing addresses at call sites, for inline caches
• Flushing the instruction cache

Second, updating vm/os-*-arm.hpp with the following:

• Reading and writing stack pointers and program counters from ucontext structures

The existing CPU and OS-specific header files can be used as a guide.

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. An ARM assembler already exists in basis/cpu/arm/assembler, but it might need to be expanded with additional opcodes.

Porting the optimizing compiler

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 performs well enough to be used for real applications.

Benefit to the student

The student will gain experience in porting a real-world compiler and VM 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. The student will also need to do space profiling of the Factor image and identify where more space-efficient data structures can be used.