Where to

Areas

Here's the areas we work in:

Core Developer tools Libraries Multicore
Tools needed by all ARM products, or bases that others can build tools on Tools used by end developers to make or debug products that make the most of the hardware Libraries used by many ARM products, or that help others build on Use all of the SoC through easier multicore programming or easier use of the non-ARM cores on a SoC

such as:

Core Developer tools Libraries Multicore
Compilers Debuggers Standard C library Parallel languages
Assembler Profilers Codecs Inter-core communication
Linker Trace tools Graphics primitives Across-SoC development
Emulation

Picking some tools as examples:

Core Developer tools Libraries Multicore
GCC, as all products need a good, fast compiler GDB, as all products need a debugger GLIBC, as all products need a good C library and loader, and some products build on the new features Renderscript, as it simplifies multicore on Android
LLVM, as others build interesting tools on it SystemTap, as others build profiling and trace tools on it libffi, as others use it to support new and unusual languages OpenMP, as it simplifies multicore on many platforms
PENDING: SSL/crypto library

Different tools needed different levels of effort. Primary products are ones that we always work on, support, and release monthly. Secondary products are ones that we work on as needed, support, and release on demand. Focuses are areas we work on in a burst, release on completion, and then move on.

Some examples are:

Primary Secondary Focus
GCC GLIBC libffi
LLVM binutils SystemTap
GDB valgrind Skia
perf Python performance

A secondary product often has a healthy upstream with good releases that we can defer to.

Topics

Some topics are cross cutting, and tie together effort across the areas. We can use this to tie together the groups efforts and fit in things that don't fit into a strict taxonomy.

Some examples are

Dalvik:

  • Tune GCC to generate the best code for the interpreter and support libraries
  • Improve the fast interpreter itself
  • Improve the JIT itself
  • Add cross-language debugging to GDB to debug mixed Java and NDK code
  • Add system level sampling profiling via perf for mixed interpreter, JIT, C, and kernel code
  • Add trace points via SystemTap for startup time profiling

  • Use profiling to convert hotspots in Java into LLVM byte code for automatic install time optimisation on the device

Renderscript:

  • Work on LLVM to improve the quality and speed of the final code
  • Work on LLVM to decrease the device footprint or installation time
  • Tune GCC to generate the best code for the Renderscript runtime
  • Improve the developers tools through adding GDB, trace, and profiling

Browser:

  • Tune GCC to generate the best code for the JavaScript interpreter and runtime

  • Tune and integrate codec libraries to reduce render time
  • Supply good graphics primitives to speed complex CSS renders

Handling ARMv8

ARMv7 is the lead architecture and will be with us for some time. Run ARMv8 in parallel with a bootstrap team first then spread across the rest of the group.

The bootstrap team will:

  • Pull ARMv8 support into the primary products
  • Add ARMv8 support in all areas
  • Add spot support for ARMv8 in tools that are part of the broader toolchain

Excluded

Some things that we're not working on are:

  • Security
  • Size of programs, unless it improves performance
  • Porting a JavaScript JIT or Dalvik to ARMv8, as it overlaps with Google's work

  • Unusual languages like Pascal, Haskell, or Erlang

Teams

Primary products may need specialised knowledge and/or fixed staffing.

Secondary or Focus work may need specialised knowledge best done via contractors.

Integration with distributions and derivatives like binary builds will be done by Platforms.

Auto builds, tests, and benchmarks, will be implemented and tracked by toolchain using the tools from the LAVA development team and infrastructure from the validation team.

We need development and release test support as part of the teams.

General

We produce things so that others have a checkpoint they can pick up our work from. This means:

  • Everything is upstream
  • A release exists on Launchpad
  • A hand over document says what was done, where it is, and how to reproduce it

MichaelHope/Sandbox/WhereTo (last modified 2012-07-30 03:12:24)