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_PortAPI_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.

Each platform would have its own set of header files where these macros are defined. For clarity, it would be best to divide the macros by module. The current proposal is to have one file for each of

• MMgc
• NanoJIT
• other modules

For example, the header file for the NanoJIT (portingapi_nanojit.h) would look like this for Win32/x86:

// no-op. not required for P5 or later.
#define NanoJIT_PortAPI_FlushInstructionCache(_start, _end)

For WinCE/ARM:

#define NanoJIT_PortAPI_FlushInstructionCache(_start, _end) FlushInstructionCache(GetCurrentProcess(), _start, (_end - _start))

For Symbian:

#include <e32std.h>
#define NanoJIT_PortAPI_FlushInstructionCache(_start, _end) User::IMB_Range(_start, _end)

For some hypothetical platform that requires an implementation that is more than one line and best implemented in a functon:

#include <somefile.h>
extern void NanoJIT_PortAPI_FlushInstructionCache_Impl(void*, void*);
#define NanoJIT_PortAPI_FlushInstructionCache(_start, _end) NanoJIT_PortAPI_FlushInstructionCache_Impl(_start, _end)

Another advantage of this method is to avoid platform ifdefs around the #include blocks. The includes would be defined in each platform's portingapi_<module>.h file.

Posix/stdlib functions

Currently, all of the supported platforms have implementations of the common posix/stdlib functions such as alloca, malloc, fopen, fwrite, memcpy, memset, etc., but in some cases these are provided through an additional framework or shim layer and less efficient than calling the equivalent native API functions. Also, some platforms have no implementation of some or all of these functions. In order to support more platforms and to increase efficiency on some others, a next step would be to replace the direct calls to these functions with the same type of macros.

Discussion Points

The following have been summarized from bugzilla or email threads.

Why marcos? Why not inline functions?

• Not all compilers have a directive to force a function to be inline, and even those that do aren't always consistent. Macro behavior is more consistent across compilers.
• Macros can be undefined and redefined, while inline functions can not. Many of the macros may be the same across several platforms except for a few exceptions, so the platform specific file could just include the common file redefine the exceptions. If the definitions were inline functions, the platform specific file would have to define everything.