Launching is done in two steps. The first step starts launching with three different options, while the second step comprises the the actual launcher.

1. Step
   • Eclipse Launcher: In Eclipse it possible to define run configurations and perform a run. This event is handled by the launcher.
   • Standalone Launcher: The launcher can be started on the command line.
   • Test Launcher: The launcher is started directly by running as a regular application. This can be handy for debug purposes, see below.
2. Step
   • deep Launcher: This is the actual launcher. Important methods are buildAll(…), downloadTargetImage(…) and startTarget(…).

1. Parse and load configuration
2. Classfile reader: loads all necessary classes, read Bytecode and build object directory
3. Initialize Linker and code generator
4. Create type descriptor for arrays
5. Create type descriptor for interfaces (interfaces which need a type descriptor only)
6. Loop One: For all regular classes
   • Prepare constant block (per class)
   • Create CFG (per method)
   • Create SSA (per method)
   • Create machine code (per method)
   • Calculate necessary memory size
7. Linker: put together system table
8. Linker: fix memory map
9. Calculate absolute addresses for arrays
10. Calculate absolute addresses for interfaces
11. Loop Two: For all regular classes
    • Calculate absolute addresses
12. Linker: create constant table
13. Loop Three: For all regular classes
    • Constant block, enter absolute addresses
    • Code generator: do fixup (per method)
14. Linker: complemend system table with information about class addresses
15. Linker: create target image (per segment)

In the package org.deepjava.launcher there is also a standalone launcher. It can be started from the command line and accepts a deep project file together with a configuration as parameters. It compiles and links but does not download to a target.

Usage: java org.deepjava.launcher.StandAloneLauncher [/config ConfigName] deepfile

  /config     By default the project is compiled for "BootFromRam".
              By specifying this switch, you can set a different
              configuration to compile for.
  /map        Dumps a mapfile
  deepfile    Project file you want to compile

e.g.

cd <absolute_path>/Test>
java -cp "<absolute_path>/org.deepjava.compiler/bin" org.deepjava.launcher.StandAloneLauncher -map -config BootFromRam Test.deep

or if the compiler is packed into a jar file

java -cp <absolute_path>/compiler.jar org.deepjava.launcher.StandAloneLauncher -map -config BootFromRam Test.deep

The TestLauncher is a helper class to start building projects directly from the eclipse development workspace without loading the deep plugin in the first place. The TestLauncher has to be launched as Java application with appropriate parameters. Arguments could be:

• –deepfile 555ExampleProject.deep –targetconfig BootFromRam
• –deepfile microzedExampleProject.deep –targetconfig BootFromRam –interface-files-path “<path>/org.deepjava.trglib”
• –deepfile junitHostTest.deep –targetconfig BootFromRam
• –deepfile microzedjunitTarget.deep –targetconfig BootFromRam

In order to test the eclipse development workspace you can start the workspace as eclipse application. For this purpose a directory has to be chosen as new workspace under Run Configuration → Main → Workspace Data → Location.
As arguments for the VM standard settings can be used. If an error like java.lang.OutOfMemoryError: PermGen space occurs more space for eclipse has to be added. This is achieved by adding the argument -XX:MaxPermSize=512m. If the heap size is too small it can be enlarged with the argument -Xmx.
Important: If the application is startet with Debug-As instead of Run-As then hot code replacement works for most changes.
In the eclipse instance all plugins under development - namely deep - can be used. A new deep project can be created. In this project you can implement any new application which you specify as root class in the deep project file. You have to modify the build path of the project so that the classes of the runtime system can be found. With Add External Class Folder you have to add the bin directory of the runtime system. Of course you could also use a test class from the runtime system as root class.
If you debug an application and want the source lookup wo work properly you have to enter the src directory of the runtime system in build path → Libraries → Source Attachment.
If one of the root classes is a class from again another library like junitTarget you must add the bin directory of this library. Here again you may want to setup the source attachment correctly.