When you start the “hardware” using the command “./pint”40 you may append addi-tional options:
where the square brackets “[]” indicate a choice, and the “+” indicates one or more repetitions. Further emulator options used for debugging are described in section 15.2 on page 104.
The hardware emulator options apply thoughout the session, and are:
-v Display the version of the Pint software and exit.
-h Display a short help message and exit.
-translate The translator converts the user’s .pint files to the .erl source files used by the hardware emulator. These are normally created automatically by the Pint system using the translator. You may modify this default behaviour.
• auto When you update a .pint source file, Pint detects that the source is newer than the existing .erl translation and creates a new .erl file. auto is the default option and does not normally need to be specified.
• new Pint re-translates your .pint files, even if an up-to-date translation exists already. This is useful if you are developing extensions to the Pint platform and need to test the translator. Example: ./pint -translate new
Do not use this option unless you really need new .erl files, since the translations slow down your session.
-compile The Erlang compiler converts .erl files created by the translator to exe-cutable .beam files. The exeexe-cutable files are normally created automatically by the Pint system, but you may modify this default behaviour.
• auto When you update a .pint source file, and translate it, Pint detects that the translation is newer than the existing .beam and creates a new .beam file. auto is the default option and does not normally need to be specified.
40The shell script pint takes your options and executes erl -run pint -extra opt1 ... optn.
13.4 Hardware emulator options 101
• native By default, the .beam files use the Erlang Beam emulator. By specifying native you can call for native code compilation, provided that your Erlang installation has HiPE enabled.
• new Pint re-builds all the .beam files. This is useful if you have just up-graded your Erlang installation, or if you are switching to or from native node compilation. Example: ./pint -compile native new
Do not use this option unless you really need new .beam files, since the compilations slow down your session.
-gc n The garbage collector closes boxes during a garbage collection sweep performed when every nth ¶fin process is executed. By default41 n = 20 but this may be changed with the “-gc n” option. A low value of n keeps the footprint as small as possible, but consumes processing power. Specifying a larger value may make your program a little faster, but the footprint will grow. See chapter 9.1.3 on page 59.
-profile This option offers a simple profiling42of your Pint program. The “hardware”
will measure the activity of each of the paths, and display a summary of the result when the program terminates. The summary is also recorded in the log file.
The -profile option will slow down your program by an amount which depends on the footprint. A program with a small footprint, < 30 channels, will be some 5% slower, but a program with a 1000 channel footprint will slow down by at least 25%.
Here is an extract from a profile:
714 Path activity counts:
715 Worker alu.int.comp, alu 3253
716 ALU template alu.int.comp, alu 3253
717 ¶fin, avl_i[97.41] 661
718 Var le23, avl_i[275.21] 276
719 Var gt, avl_i[360.26] 263
720 ¶fin, avl_i[407.23] 263
721 Var gt, avl_i[390.26] 263
722 Prole var c, avl_i[403.24] 263
723 Var le21, avl_i[274.21] 256
724 Anonymous abstraction 200
725 ¶fin, rns[34.45] 200
726 Random integer template rng.uniform.ints, rng 200
The integer value is the number of π-reductions on the path. Do we really need all those integer comparisons? Perhaps we need a hardware accelerator for the AVL tree.
41Note to myself: Function launch_box_mgr in pint.erl.
42The Erlang library stdlib also offers functions for profiling Erlang programs such as the translations of your .pint programs. However there appears to be an interaction between the Erlang profiling and the Pint hardware emulator which prevents its use.
14 Running Pint programs
At last, the moment of truth arrives, and we try to run our program. What further nasty surprizes await?
There is only one command43 to translate, compile, load and run a Pint program:
pi. This command is to be used in the working directory44. It:
1. Checks that the OASIS catalogue is up to date and if necessary re-compiles it.
2. Reviews the source code looking for the import declarations. If any of these declarations points to a program which has been modified since the most recent translation, the entire program is retranslated to form a new .erl file.
3. Compiles any new .erl file to form a new .beam file, which is the executable form of a Pint program.
4. Checks that the program is not running already. This can happen if you attempt to launch a distributed program onto two or more nodes, but mistakenly specify your own node for one of the remote nodes. If it is already running, stop the running instance and unload it.
5. Loads and launches the executable program.
The command pi has three forms:
pi(program ) Attempt to run the program declared as entity program in the OASIS catalogue. The footprint must fit onto no more than the default number of channels made available by the Pint platform.
pi(program ,N ) Attempt to run the program declared as entity program in the OASIS catalogue. The footprint must fit onto no more than N hardware channels.
Do not set unrealistically high values of N. Not only will this slow down your program, but it may hide a channel leak due to erroneous use of the garbage collector.
pi(program ,N ,[node1. . . noden]) Attempt to run the program declared as entity program in the OASIS catalogue. The footprint must fit onto no more than N hardware channels. The program is to be run on the local node, also known as the principal node and on the nodes node1 . . . noden. See line 546 on page 84 for an example.
Good luck!
14.1 Stopping Pint programs
Sometimes, one’s luck runs out. Particularly during demonstrations to important cus-tomers.
There are a number of ways of stopping a Pint program in addition to programmed terminations using ¶die and ¶postmortem.
The simplest is to enter Ctl-G and then Q at the console. This will kill the Pint session but may leave the emulator in an endless loop. To kill the emulator, enter
43Almost true! pi is an alias defined in program user_default.erl for the command pint:load.
44This requirement may be relaxed when we have more experience of use of the OASIS catalogue.
14.1 Stopping Pint programs 103
the killall instruction given when the session starts. This is typically killall -i run.x86-linux.
15 Debugging
The Pint platform provides debugging facilities at compile time and at run time. In both cases, detailed information may be placed in the log file.
When you translate a program45, the translator creates a log file file.log in the same directory as the source file. If such a log file existed previously, it is erased. The translator’s report on your program, and the run time traces and error reports are written into this file. You may write into the log file from your program by directing your output to the devicestdErr. You do not need to open stdErr, Pint does this for you.
15.1 Translate time debugging
The translator provides information which is useful for debugging, and performs a num-ber of checks, in addition to the usual lexical and syntactic checks. For example:
Automatic typing The translator searches for a type judgement which provides a fully ground type for each path used in your program. “Fully ground” means that there are no type variables or type polymorphism in the final judgement. This judgement is displayed in the .log file. See chapter 5 for more detail.
Boxes and garbage collection The .log file includes full details of the boxes de-termined by the translator.
Cross reference The .log file includes a listing of the all the variables in your program, and for each variable, a list of places where the variable is used.
DTD The .log file includes a complete statement of the DTD applicable to the elements and attributes used; no matter how well the programmer has hidden the elatt declarations.
· · ·
Zero tolerance The translator does not allow a program translation to succeed if it produces any errors or warnings, no matter how slight. For example, all sets of patterns must be complete and irredundant.
A programmer hacking into the translator can also add a great deal more information to the log file by setting to true the trace flags in program trace.sml.