Edit: Factor/GSoC/2009/Port Factor to ARM

= 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 [[Factor/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 [[Factor/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.

Describe this revision:

Save