Jump to: navigation, search

DSDP/RTSC - xdc.runtime.knl

< DSDP
Revision as of 21:44, 8 December 2008 by D-russo.ti.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

The target runtime provided with XDCtools, xdc.runtime, provides a number of services that enable components to be written in a 100% platform independent manner; basic "printf" output, memory management, embeddable runtime diagnostics, and even some mutual exclusion support. Some components, however, require the ability to create and manage more than one thread; e.g., TCP/IP communication stacks are often implemented using multiple threads.

By adding threading services to xdc.runtime (or creating a separate xdc.runtime.knl package), components that need basic thread services can deployed on any platform that supports xdc.runtime (and xdc.runtime.knl). In other words, adding threading services to xdc.runtime extends the OS abstraction already provided by xdc.runtime and allows a much greater number of components to be portable across a number of executation platforms: Linux, DSP/BIOS, Windows, ...

A second reason to add basic threading services to xdc.runtime is to enable the creation of "OS compatibility" packages. For example, a package that provide POSIX 103 support atop xdc.runtime.* would enable a wide variety of POSIX based components to be quicly migrated to any platform supporting xdc.runtime.*. One such example, is OpenMP; at least one implementation of OpenMP relies on POSIX 1.03 to implement local threads. By enabling POXIX 103 on any platform that supports xdc.runtime.*, we immediately enable all pure POSIX apps (such as OpenMP) to operate on the same set of platforms.

Goals

  • it should be "easy" to implement the required interfaces using popular embedded runtime environments; e.g., WinCE, Linux, DSP/BIOS, etc.
  • the overhead of the threading interfaces, relative to direct use of the underlying RTOS, should be kept to a minimum. More specifically:
    • ideally, runtime overhead should only be incurred during instance creation/deletion.
    • existing applications that directly use DSP/BIOS and that can be modified to use the new threading services, should continue to fit in existing platforms after being converted to use the new APIs.

Requirements

  • for components that do not require threads, performance is unaffected: no additional code, data, or runtime overhead occurs as a result of this extension.

Resources