=========================================
llvm-rs-cc: Compiler for ScriptC language
=========================================


Introduction
------------

llvm-rs-cc compiles a program in the ScriptC language to generate the
following files.

* Bitcode file. Note that the bitcode here denotes the LLVM (Low-Level
  Virtual Machine) bitcode representation, which will be consumed on
  an Android device by libbcc (in
  platform/frameworks/compile/libbcc.git) to generate device-specific
  executables.

* Reflected APIs for Java. As a result, Android's Java developers can
  invoke those APIs from their code.

Note that although ScriptC is C99-like, we enhance it with several
distinct, effective features for Android programming. We will use
example usage below to illustrate these features.

llvm-rs-cc is being run on a host and is highly-optimizing. As a
result, libbcc on the device can be lightweight and focus on
machine-dependent code generation given some bitcode.

llvm-rs-cc is a driver on top of libslang. The archictecture of
libslang and libbcc is depicted in the following figure::

    libslang   libbcc
        |   \   |
        |    \  |
     clang     llvm


Usage
-----

* *-o $(PRIVATE_RS_OUTPUT_DIR)/res/raw*

  This option specifies the directory for outputting a .bc file.

* *-p $(PRIVATE_RS_OUTPUT_DIR)/src*

  The option *-p* denotes the directory for outputting the reflected Java files.

* *-d $(PRIVATE_RS_OUTPUT_DIR)*

  This option *-d* sets the directory for writing dependences.

* *-MD*

  Note that *-MD* will tell llvm-rs-cc to output dependences.

* *-a*

  Specifies additional dependence target.

Example Command
---------------

First::

  $ cd <Android_Root_Directory>

Using frameworks/base/libs/rs/java/Fountain as a simple app in both
Java and ScriptC, we can find the following command line in the build
log::

  $ out/host/linux-x86/bin/llvm-rs-cc \
    -o out/target/common/obj/APPS/Fountain_intermediates/src/renderscript/res/raw \
    -p out/target/common/obj/APPS/Fountain_intermediates/src/renderscript/src \
    -d out/target/common/obj/APPS/Fountain_intermediates/src/renderscript \
    -a out/target/common/obj/APPS/Fountain_intermediates/src/RenderScript.stamp \
    -MD \
    -I frameworks/base/libs/rs/scriptc \
    -I external/clang/lib/Headers \
    frameworks/base/libs/rs/java/Fountain/src/com/android/fountain/fountain.rs

This command will generate:

* **fountain.bc**

* **ScriptC_fountain.java**

* **ScriptField_Point.java**

The **Script\*.java** files above will be documented below.


Example Program: fountain.rs
----------------------------

fountain.rs is in ScriptC language, which is based on the standard
C99. However, llvm-rs-cc goes beyond "clang -std=c99" and provides the
following important features:

1. Pragma
---------

* *#pragma rs java_package_name([PACKAGE_NAME])*

  The ScriptC_[SCRIPT_NAME].java has to be packaged so that Java
  developers can invoke those APIs.

  To do that, a ScriptC programmer should specify the package name, so
  that llvm-rs-cc knows the package expression and hence the directory
  for outputting ScriptC_[SCRIPT_NAME].java.

  In fountain.rs, we have::

    #pragma rs java_package_name(com.android.fountain)

  In ScriptC.fountain.java, we have::

    package com.android.fountain

  Note that the ScriptC_fountain.java will be generated inside
  ./com/android/fountain/.

* #pragma version(1)

  This pragma is for evolving the language. Currently we are at
  version 1 of the language.


2. Basic Reflection: Export Variables and Functions
---------------------------------------------------

llvm-rs-cc automatically export the "externalizable and defined" functions and
variables to Android's Java side. That is, scripts are accessible from
Java.

For instance, for::

  int foo = 0;

In ScriptC_fountain.java, llvm-rs-cc will reflect it to::

  void set_foo(int v)...

  int get_foo()...

This access takes the form of generated classes which provide access
to the functions and global variables within a script. In summary,
global variables and functions within a script that are not declared
static will generate get, set, or invoke methods.  This provides a way
to set the data within a script and call to its functions.

Take the addParticles function in fountain.rs as an example::

  void addParticles(int rate, float x, float y, int index, bool newColor) {
    ...
  }

llvm-rs-cc will genearte ScriptC_fountain.java as follows::

  void invoke_addParticles(int rate, float x, float y,
                           int index, bool newColor) {
    ...
  }


3. Export User-Defined Structs
------------------------------

In fountain.rs, we have::

  typedef struct __attribute__((packed, aligned(4))) Point {
    float2 delta;
    float2 position;
    uchar4 color;
  } Point_t;

  Point_t *point;

llvm-rs-cc generates one ScriptField*.java file for each user-defined
struct. I.e., in this case llvm-rs-cc will reflect to two files,
ScriptC_fountain.java and ScriptField_Point.java.

Note that when the type of exportable variable is struct, ScriptC
developers should avoid anonymous structs. This is because llvm-rs-cc
uses the struct name to name the file, instead of the typedef name.

For the generated Java files, using ScriptC_fountain.java as an
example we have::

  void bind_point(ScriptField_Point v)

This binds your object with the allocated memory.

You can bind the struct(e.g., Point), using the setter and getter
method in ScriptField_Point.java.

After binding, you could get the object from this method::

  ScriptField_Point get_point()

In ScriptField_Point_s.java::

    ...
    // Copying the Item, which is the object that stores every
    // fields of struct, to the *index*\-th entry of byte array.
    //
    // In general, this method would not be invoked directly
    // but is used to implement the setter.
    void copyToArray(Item i, int index)

    // The setter of Item array,
    // index: the index of the Item array
    // copyNow: If true, it will be copied to the *index*\-th entry
    // of byte array.
    void set(Item i, int index, boolean copyNow)

    // The getter of Item array, which gets the *index*-th element
    // of byte array.
    Item get(int index)

    set_delta(int index, Float2 v, boolean copyNow)

    // The following is the individual setters and getters of
    // each field of a struct.
    public void set_delta(int index, Float2 v, boolean copyNow)
    public void set_position(int index, Float2 v, boolean copyNow)
    public void set_color(int index, Short4 v, boolean copyNow)
    public Float2 get_delta(int index)
    public Float2 get_position(int index)
    public Short4 get_color(int index)

    // Copying all Item array to byte array (i.e., memory allocation).
    void copyAll()
    ...


4. Summarize the Java Reflection above
--------------------------------------

Let us summarize the high-level design of reflection next.

* In terms of script's global functions, they can be called from Java.
  These calls operate asynchronously and no assumptions should be made
  upon with a function called will actually complete operation.  If it
  is necessary to wait for a function to complete the java application
  may call the runtime finish method which will wait for all the script
  threads to complete.  Two special functions also exist:

  * The function **init** present will be called once after the script
    is loaded.  This is useful to initialize data or anything else the
    script may need before it can be used.  The init may not depend on
    globals initialized from Java as it will be called before these
    can be initialized.

  * The function **root** is a special function for graphics.  Which a
    script must redraw its contents this function will be called.  No
    assumptions should be made as to when this function will be
    called.  It will only be called if the script is bound as root.
    Also calls to this will be synchronized with data updates and
    other invocations from Java.  Thus the script will not change due
    to external influence during a run of **root**.  The return value
    indicates to the runtime if the function should be called again to
    redraw in the future.  A return value of 0 indicates that no
    redraw is necessary until something changes.  Any positive integer
    indicates a time in ms that the runtime should wait before calling
    root again to render another frame.

* In terms of script's global data, global variables can be written
  from Java.  The Java class will cache the value or object set and
  provide return methods to retrieve this value.  If a script updates
  the value, this update will not propagate back to the Java class.
  Initializers if present will also initialize the cached Java value.
  This provides a convenient way to declare constants within a script and
  make them accessible from the java runtime.  If the script declares a
  variable const, only the get methods will be generated.

  Globals within a script are considered local to the script.  They
  cannot be accessed by other scripts and are in effect always 'static'
  in the traditional C sense.  Static here is used to control if a
  accessor is generated.  Static continues to mean *not
  externally visible* and thus prevents the generation of
  accessors.  Globals are persistent across invocations to a script and
  thus may be used to hold data from run to run.

  Globals of two types may be reflected into the Java class.  The first
  type is basic non-pointer types.  Types defined in rs_types.rsh may be
  used.  For the non-pointer class get and set methods are generated in
  Java.  Globals of single pointer types behave differently.  These may
  use more complex types.  Simple structures composed of the types in
  rs_types.rsh may also be used.  These globals generate bind points in
  java.  If the type is a structure they also generate a **Field** class
  used to pack and unpack the contents of the structure.  Binding an
  allocation to one of these bind points in Java effectively sets the
  pointer in the script.  Bind points marked const indicate to the
  runtime that the script will not modify the contents of an allocation.
  This may allow the runtime to make more effective use of threads.


5. Vector Types
---------------

Vector types such as float2, float4, and uint4 are included to support
vector processing in environments where the processors provide vector
instructions.

On non-vector systems the same code will continue to run but without
the performance advantage.  Function overloading is also supported.
This allows the runtime to support vector version of the basic math
routines without the need for special naming.  For instance,

* *float sin(float);*

* *float2 sin(float2);*

* *float4 sin(float4);*