Write C source code and verify correct operation.
Edit .c source code (degenerate integration) by placing guest code within host function (at end).
Compile .c to .s with GCC targeting your architecture: gcc -S -O3 foo.c (no debug info!). –O1 –g doesn’t reorder code. (Only gcc is supported for the Alpha).
If run-time cycle counting is needed, add commented out rpcc instructions to the .s file
Add labels to identify explicit guest basic blocks. Be sure to mark the first and last guest blocks explicitly, even if they have no timing constraints. Thrint needs these marked to identify the intervening code as implicit or explicit guest code.
If compiling for the Alpha architecture, create the .pdg file on Aslan: pcom -gpdg -Gscreen foo.s > foo.pdg.txt

Edit foo.pdg.txt

If run-time cycle counting is needed, add rpcc instructions.
Replace _$ with $
Modify loop iteration counts if pcom didn’t get them. Also, put it ? for unknown iteration count loops.

Edit .s file

If run-time cycle counting is needed, uncomment rpcc instructions.

On a SunOS Sparc workstation, (walk-through starts with these steps)

Create an integration directives file foo.id. For example, this one tells Thrint to move Guest1 to start executing within five cycles of cycle 35:

PROCEDURE ReconBMBlock_en INTO ReconBMBlock_en

TOLERANCE 5

BLOCK Guest1 AT 35

END

Use Thrint to integrate and create .int.s file: thrint -i -hl –hv foo.pdg.txt

Thrint automatically saves and restores 6 registers on stack for guest to use
-hl is a useful command line switch to avoid printing out ldgp instruction (helpful for alpha).
-hv disables timing verification after integration.

On an Alpha machine,

Add in the debug and symbol information
make integrated application
Run your code!

2 Walk-Through

2.1 Original Source Code

The C++ source code below was compiled on an Alpha workstation to assembly code, had meaningful guest code labels inserted, and was processed with PCOM. The two output files used are line.pdg.txt and line.s .

2.2 Examining Program Structure

2.2.1 Graph Generation Example

We use XVCG (in the imagetools locker, %add imagetools ) to convert .vcg files created by Thrint into graph diagrams in an XWindows environment.

Begin with the program line.pdg.txt . You need to create an .id file (line.id ) to identify the first and last guest nodes in the function.

PROCEDURE VidRef_LineDraw__Fv_en INTO VidRef_LineDraw__Fv_en

TOLERANCE 0

BLOCK Video_Reset_Ptr AT 20

LOOP Video_Loop PERIOD 40 ITERATION_COUNT 128

BLOCK Video_Pix0 INTO_LOOP Video_Loop FIRST_AT 100

BLOCK Video_Pix1 INTO_LOOP Video_Loop FIRST_AT 110

BLOCK Video_Pix2 INTO_LOOP Video_Loop FIRST_AT 120

BLOCK Video_Pix3 INTO_LOOP Video_Loop FIRST_AT 130

BLOCK Video_End IMPLICIT

END

Run thrint and request a graph of the CDG.

thrint –G –hd line.pdg.txt

This generates a file (line.VidRef_LineDraw__Fv_en.int.vcg) which is a text description of the program’s control dependence graph. View it by running xvcg. The –hd is a hack switch to disable processing of directives, which are not completely supported for the Alpha yet.

xvcg line.VidRef_LineDraw__Fv_en.int.vcg &

A small version of the resulting graph is shown above. Yellow nodes are guests, while all others are hosts (or overhead – more information later). Deep yellow nodes are guests with explicit timing requirements – they must execute at a specific target time range. Pale yellow nodes are guests with implicit timing requirements – they have no such target time range, but must be executed after the preceding guest and before the following guest node.

Each node contains several pieces of information when the basic –G option is specified.

Name
Type and label
Start time range in processor instruction cycles. [Best Case .. Worst Case] X indicates invalid or unknown.
Duration range in processor instruction cycles.
The red line indicates this node is executed on a False condition (a not-taken branch).

The vcg filename consists of the original program filename concatenated with the name of the function. If there are multiple functions in the file, multiple vcg files will be created. Also, to save typing, take advantage of filename completion in the command shell by pressing tab to fill in predictable filename characters.

XVCG will create a PostScript file from the command line for a file bar.vcg with the following command format: xvcg –psoutput bar.ps –color –landscape bar.vcg. This is useful, and you may want to create an alias to automate this process.

2.2.2 Graph Generation Options

There are three options for examining a program’s CDG structure in Thrint.

Thrint can generate .vcg files (for display by XVCG) with the –G option. One file is generated for each function. If integration is not selected, the output files created will be named file_root.procedure.vcg. If integration is selected (-i), the output files will be named file_root.procedure.int.vcg.
Thrint can generate a vcg file and update it after each change to the program (e.g. padding, code motion, code replication). Use this option (-Ga) when debugging in order to better understand the current program structure. Select File->Reload in XVCG to refresh the display after stepping over a procs->Gen_Graphs() call.
Thrint can spawn XVCG and control its refreshes with the option -GA . In this case, the user needs to press enter on the keyboard to force Thrint to proceed to the next code transformation. This feature is not implemented currently.

Thrint can include the instructions and register use information in each node. Use –Gi for this option.

CDGs get large quickly. To reduce node size for XVCG, specify –Gs to instruct Thrint to eliminate all text from the nodes, leaving just shape, color and structure to indicate the CDG.

2.3 Examining Host Function Temporal Determinism

By specifying the –Th switch, Thrint generates two plots of temporal (timing) determinism within a host function. This option is automatically enabled integration is requested. Temporal determinism decreases as jitter (timing variation) increases. Thrint builds temporally deterministic segments by appending CDG nodes to the current segment until the jitter exceeds a certain threshold (set to ### cycles with –j###, default value of 3000 cycles), at which point a new segment is begun. Each segment is stored in a list for consideration as a potential target for guests when planning integration.

thrint –Th –hd –j100 line.pdg.txt

Note: the number of iterations for loop $39 is unknown, so the number of iterations used when generating the temporal determinism plots is set to a default value.

Thrint creates two data files (one for jitter, one for the segment execution profile) for each host procedure in the program, e.g. line.VidRef_LineDraw__Fv_en.j.dat and line.VidRef_LineDraw__Fv_en.s.dat in this case. Two GNUPlot command scripts (line.j.gpc and line.s.gpc) are also created to allow the user to view the graphs. The following command displays the graph for segments:

gnuplot line.s.gpc

If thrint is called with the –ow web output command (thrint –Th –hd –j100 –ow line.pdg.txt) the gnuplot command script will create postscript output (line.VidRef_LineDraw__Fv_en.j.ps and line.VidRef_LineDraw__Fv_en.s.ps).

The first plot below shows the deterministic segment found within the host function VidRef_LineDraw_Fv_en in line.pdg.txt. The vertical axis shows the maximum jitter as a function of progress through the program. In this case we see the effect of unbalanced conditionals within the loop $39. Each iteration adds eight cycles of jitter to the total.

All acceptable deterministic segments in the function are plotted in the same graph.

The second plot is essentially the derivative of the first plot. It shows how much jitter each node adds to the segment’s cumulative jitter, and is generated with this command:

gnuplot line.j.gpc

2.4 Examining Guest Function Idle Time

Thrint creates a histogram showing idle time within the guest thread when the –Tg command line switch is used. The horizontal axis represents idle time bubble size (granularity), while the vertical axis represents the total amount of time available with that granularity. Thrint uses the integration directives file (line.id) to determine when each explicit guest event needs to execute.

This analysis is useful because it shows how much fine-grain idle time there is within an thread.

thrint –Tg –hd line.pdg.txt

This command creates two files, a data file and a gnuplot command file to graph the data (line.VidRef_LineDraw__Fv_en.i.dat and line.VidRef_LineDraw__Fv_en.i.gpc). Running gnuplot on the .gpc file brings up a plot window showing the histogram.

gnuplot line.VidRef_LineDraw__Fv_en.i.gpc

Once again, use the –ow option to specify a gpc file which will generate a postscript file.

2.5 Integrating Threads

2.5.1 Estimating Integration Results

Two aspects of integration estimation are currently being developed: code memory expansion and system performance. Eventually these pieces of information will be combined to create a Minimal MIPS vs. Code Memory plot for various integration options (as in the RTSS99 paper).

To estimate code memory expansion, use the –Em switch for Thrint. Currently under development.
To estimate system performance (how many MIPS are required), use the –Ep switch. Currently under development.

2.5.2 Performing Thread Integration

The –i switch specifies integration and automatically enables host timing analysis. Use –hd to disable directive processing. The switch –hv will disable timing verification; otherwise Thrint will complain that several guests don’t meet their timing tolerances. Thrint needs to be extended to properly evaluate the timing of guest loops which have been split.

thrint –G –i –hd -hv line.pdg.txt

This will create several files.

line.int.s is the integrated assembly file.
VidRef_LineDraw__Fv_en.int.log contains a list of integration activities performed.
line.VidRef_LineDraw__Fv_en.int.vcg describes the CDG of the integrated code, shown below ( full-size here ).

3 Test Files

These sample programs will be available to help you test your code. Start with line.pdg.txt.

3.1 Alpha Test Files

Directory	File	Notes
Test/Simple/	test1.pdg.txt
	test2.pdg.txt
	test2a.pdg.txt
	test2b.pdg.txt
	test2c.pdg.txt
	test3.pdg.txt
	test3big.pdg.txt
	test3idle.pdg.txt
	test3loop.pdg.txt
Test/NTSC/	circle.pdg.txt
	sprite.pdg.txt
	line.pdg.txt
Test/LCD/	LCD3.pdg.txt