CPUs, boards, programmers and runtime systems are described by configuration files. These files must be put into the directory config in the target library. Within config there are 5 subdirectories: base, arch, cpus, boards, operatingsystems and programmers. These subdirectories are scanned for configuration files. All files found will be parsed. Whenever a new project is created the desired target library has to be declared.

Configuration files have the ending .deep. They are pure text files with the syntax described in Syntax for Configuration Files.

Example:

#deep-1

meta {
	version = "2014-01-06";
	description = "CPU description file for myCPU";
}

cpu MyCPU {
	description = "Example CPU";
	arch = ppc32;
	
	sysconst {
		MyConstant = 0x548;
	}
	
	memorymap {
		device MyRamDev {
			attributes = read, write;
			width = 4; size = 0x10000; base = 0x0;
			technology = ram;
		}
		segment MyRamDev.Seg1 {
			base = sysTabBaseAddr;
			attributes = read, write, systab;
		}
		segment MyRamDev.Seg2 {
			attributes = read, write, const;
		}
	}
	
	registermap {
		register MSR {
			 type = MSR; addr = 1; size = 4;
		}
		 register CR {
			 type = CR; addr = 1; size = 4;
		}
	}
}

A configuration file starts with #deep-1, whereas the number stands for the syntax version. Next comes a meta information block followed by all the other blocks in arbitrary order.

A comment starts with # and go to the line end. The exception to this is the keyword on the first line.

Each deep file contains one or more of the following blocks:

• meta
  Contains version information and a description of the file, must be first block in every file.
• compiler
  Contains constants for the compiler. These constants are used by the compiler to build the system table or to tell it how the stack frame has to be constructed. These constants are also used by the runtime system, e.g. the kernel. Typically compiler contains the block sysconst.
• arch
  Describes an architectureBeschreibt eine Architektur. Typically contains a block registermap.
• cpu
  Describes a CPU. Typically contains blocks cpuarch, sysconst, memorymap und registermap. cpuarch indicates the CPU architecture, sysconst defines further system constants and registermap defines further registers. memorymap describes memory external to the CPU.
• board
  Defines a board. Typically contains blocks cputype, sysconst, memorymap, reginit und runconfiguration. cputype describes the CPU, sysconst defines further system constants, memorymap describes memory external to the CPU, in reginit you can gives initial values for registers. For runconfiguration see below.
• programmer
  Describes a programmer. Contains a description.
• operatingsystem
  Defines an operating system. Has blocks for unsafe classes, low-level classes, exception classes, heap classes, etc. For methods of exception classes you can specify method offsets here. Such an offset is not relative to the code base of its class but to the segment which this class belongs to. Important: When the configuration is loaded, for each class or method defined in this block new items will already be created and inserted into the object directory (Class File Reader) and some of the properties will be set accPropFlags, offset). These items must be reused by the class file reader later on when the system classes are loaded!

Classes to describe the configuration

Registers are defined in the architecture and in the CPU. Initial values for certain registers can be defined for a CPU and a board. System constants can be defined for a board, a CPU and as compiler constants. All these items are stored as linked lists (see figure) for efficient searching.

Lists for registers and system constants

A memory map can be given for a CPU and a board. Such a map contains several devices. For each device several segments can be specified. A segment is a memory area. As an example: device A contains a segment S1, where S1 accepts programs data (instructions). Thus, segments are logical blocks whereas devices are physical entities.
Flash devices have additionally a description of their sectors. This arrangement is physically given by the flash architecture.

A board description may contain one or several run configurations. A run configuration indicates the location of the system table(system), into which segments certain classes may be linked (modules) and may define further initial values for registers.

Alongside the configuration there exists a project file for each deep project with the name ProjectName.deep. the following tags may be defined therein:

• libpath: Gives the path of the runtime system or runtime library. It's also possible to specify jar-files. These must be given with file name and ending, e.g. “D:/work/crosssystem/bsp.jar”;.
• boardtype: You must specify a type which was defined in the configuration.
• ostype: ditto
• programmertype: ditto
• programmeropts: Not yet implemented
• tctfile: Used only for junitTests on the target. All methods which might be commands will be listed in this text file given under this tag, e.g. tctfile = “tct/targetCommands.dtct”;. With tctfile = default the default file tct/targetCommands.dtct is chosen.
• imgfile: Defines the target image file, e.g. imgfile = “W:/phycorempc5200b/test.bin”;.
• imgformat: Format for the target image file, e.g. imgfile = binary;. Currently, only binary format is supported.
• rootclasses: One or several root classes can be specified.

Hint: If you want to create a new configuration for a board, an operating system or a programmer this new configuration is obviously not yet contained in the existing runtime library. You create the new configuration file within the actual project directory and add this directory to the library path in the project file!

The configuration can be read by calling

Configuration.readProjectFile(String file)

. Subsequently you have to specify which run configuration to use.

When eclipse is used part of the configuration must be read already when a new project is created or of projects properties are changed. This is for the wizards to be able to list the various options in the combo boxes.

Part of the configuration is used by the kernel in the runtime system. This information has to go into several interface classes. If the configuration changes in this respect you have to newly create those interface files with

public static void createInterfaceFiles(String libraryPath)

.

You can call the TestLauncher with the option –interface-files-path, see TestLauncher. The following files are created:

• IdeepCompilerConstants (for system constants)
• Architecture specific interface files, e.g. Ippc32. The actual architecture (defined in the actual project) will be taken.
• Board specific interface file (system constants of the board and the CPU, registers of the CPU), e.g. IntbMpc555HB. The actual board (defined in the actual project) will be taken.

For changes in the configuration all this interface files might change as well and should be rebuilded before the runtime system can be used together with the new configuration.