Concatenative language
Concatenative topics
Concatenative meta
Other languages
Meta
= 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 [[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%. 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 [[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 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.
Describe this revision:
Save