Tamarin:Porting: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(New page: = Goals = A goal of Tamarin is to allow it to run on any platform, to this end we wish to create a standardized porting layer that is: * lightweight * simple = Details = An abstraction la...)
 
Line 14: Line 14:
   #elsif defined(MAC)
   #elsif defined(MAC)
     MacOSAPIFunction();
     MacOSAPIFunction();
   #endif
  #elsif defined(LINUX)
    LinuxAPIFunction();
   #endif
 
The resulting code is efficient, but can be difficult to read and since the platform dependencies are often scattered throughout the code, porting to a new platform will require changes across files throughout the codebase.
 
The proposed solution is to define sets of macros that replace the platform specific ifdefs with a single macro that is defined in a central location. For example for many platforms newly JITted code requires that the instruction cache be flushed. The resulting code would look something like this:
 
#if defined(WIN32)
  #if defined(UNDER_CE)
    FlushInstructionCache(GetCurrentProcess(), NULL, NULL); // Windows CE
  #else
    // Not required on Windows, assuming P5 or later.
  #endif
#elsif defined(AVMPLUS_LINUX)
  #if defined(AVMPLUS_ARM)
    // some code plus inline assembler
  #else
    // not required for x86 Linux
  #endif
#elsif defined(AVMPLUS_SYMBIAN)
  User::IMB_Range(start, end);
#endif
 
The proposal is to replace that block of code with the following macro
 
  NanoJIT_PortingAPI_FlushInstructionCache(start, end);
 
Where the macro is defined for each platform. For x86 platforms, it is defined as nothing. For ARM platforms, it is defined as the appropriate system call, a function that implements the functionality, or some inline code.

Revision as of 18:03, 9 July 2008

Goals

A goal of Tamarin is to allow it to run on any platform, to this end we wish to create a standardized porting layer that is:

  • lightweight
  • simple

Details

An abstraction layer can solve the portability issue, but at the cost of speed, stack and code size. In order to avoid this overhead, we usually add platform specific ifdefs, e.g.

 #if defined(WIN32)
  #if defined(UNDER_CE)
    WindowsCEAPIFunction();
  #else
    WindowsAPIFunction();
 #elsif defined(MAC)
   MacOSAPIFunction();
 #elsif defined(LINUX)
   LinuxAPIFunction();
 #endif  

The resulting code is efficient, but can be difficult to read and since the platform dependencies are often scattered throughout the code, porting to a new platform will require changes across files throughout the codebase.

The proposed solution is to define sets of macros that replace the platform specific ifdefs with a single macro that is defined in a central location. For example for many platforms newly JITted code requires that the instruction cache be flushed. The resulting code would look something like this:

#if defined(WIN32)
  #if defined(UNDER_CE)
    FlushInstructionCache(GetCurrentProcess(), NULL, NULL); // Windows CE
  #else
    // Not required on Windows, assuming P5 or later.
  #endif
#elsif defined(AVMPLUS_LINUX)
  #if defined(AVMPLUS_ARM)
    // some code plus inline assembler
  #else
    // not required for x86 Linux
  #endif
#elsif defined(AVMPLUS_SYMBIAN)
  User::IMB_Range(start, end);
#endif

The proposal is to replace that block of code with the following macro

 NanoJIT_PortingAPI_FlushInstructionCache(start, end);

Where the macro is defined for each platform. For x86 platforms, it is defined as nothing. For ARM platforms, it is defined as the appropriate system call, a function that implements the functionality, or some inline code.