Front Page All Articles Recent Changes Random Article

Contents

Concatenative language

  • ACL
  • Ait
  • Aocla
  • Breeze
  • Callisto
  • Cat
  • Cognate
  • colorForth
  • Concata
  • CoSy
  • Deque
  • DSSP
  • dt
  • Elymas
  • Enchilada
  • ETAC
  • F
  • Factor
  • Fiveth
  • Forth
  • Fourth
  • Freelang
  • Gershwin
  • hex
  • iNet
  • Joy
  • Joy of Postfix App
  • kcats
  • Kitten
  • lang5
  • Listack
  • LSE64
  • Lviv
  • Meow5
  • min
  • Mirth
  • mjoy
  • Mlatu
  • Ode
  • OForth
  • Om
  • Onyx
  • Plorth
  • Popr
  • Porth
  • PostScript
  • Prowl
  • Quest32
  • Quackery
  • r3
  • Raven
  • Retro
  • RPL
  • SPL
  • Staapl
  • Stabel
  • Tal
  • Titan
  • Trith
  • Uiua
  • Worst
  • xs
  • XY
  • 5th
  • 8th

Concatenative topics

  • Compilers
  • Interpreters
  • Type systems
  • Object systems
  • Quotations
  • Variables
  • Garbage collection
  • Example programs

Concatenative meta

  • People
  • Communities

Other languages

  • APL
  • C++
  • Erlang
  • FP trivia
  • Haskell
  • Io
  • Java
  • JavaScript
  • Lisp
  • ML
  • Oberon
  • RPL
  • Self
  • Slate
  • Smalltalk

Meta

  • Search
  • Farkup wiki format
  • Etiquette
  • Sandbox

Factor/GSoC/2010/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 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 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 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.

This revision created on Thu, 25 Feb 2010 19:05:13 by jckarter (copy over 2009 proposal, and update to be in line with Factor development)

Latest Revisions Edit

All content is © 2008-2024 by its respective authors. By adding content to this wiki, you agree to release it under the BSD license.