Leopold Toetsch wrote: > I'd much more prefer that a compiler (amber anyone ;) just emits PIR > with debug syntax so that folks get a feeling how it looks like...
OK, I've done this. I have modified the Amber compiler to generate PIR code that contains debug directives, so that we can discuss a real example. You can access the generated PIR file from the link on this page: http://xamber.org/temp/debug.html There is also a link to the Amber source file from which the PIR is generated (annotated with line numbers). This is for your interest only; you don't need to look at it if you are only interested in the PIR debug directives. SYNTAX USED: I have used a syntax that I found convenient to generate, but of course I will change it to whatever the Parrot project wants to use. It's a fairly minimal syntax for the most common cases, which are line numbers, file numbers and column numbers. I realise that starting these directives with a PIR comment character is controversial, however in the short term this enables the PIR to remain runnable, so I have made every directive start with "#.debug ". If that is followed by a string, it represents the current filename, e.g.: #.debug "foo.am" An integer represents a line number: #.debug 27 A colon separates line numbers and column numbers: #.debug 27:9 Other kinds of data are represented by a key (an identifier) followed by a value (a string or integer). There are two samples of this in the current PIR file. The first is a zone, which has the value "assertion" within code that evaluates assertions, and the value "" elsewhere. The second is a class_number, which is a distinct positive integer for each class, or 0 for unknown. For example: #.debug class_number 4 #.debug zone "assertion" ... #.debug zone "" ... #.debug class_number 0 SOME ISSUES FOR DISCUSSION: Amber uses natural numbers for counting, so the first column of the first line is 1:1. A line number of column number of 0 represents 'unknown'. If PIR uses a different convention, I will adjust the code generation to match. Amber sometimes generates multiple directives without any intervening PIR code. Some of these may be 0:0, for constructs where Amber isn't yet tracking the line/column number, but imcc should accept this. For example: #.debug 48:12 #.debug 0:0 #.debug 48:56 RUNNING THE PIR: If you want to run this PIR, you will need revision 9911 or later of Parrot. You have to first build the Amber PMCs: cd languages/amber ; make pmcs Then you can run it like this: parrot life.pir This runs a small text-mode display of Conway's game of life for 20 generations (takes only a few seconds). You can choose a different number of generations by adding a command-line argument: parrot life.pir 35 ERROR REPORTING: I have inserted a trap so that an exception is raised after generation 42 has been displayed. So, if you run the program like this... parrot life.pir 50 ...then you will get the following message after generation 42: This is an Amber exception raised to test error reporting. current instr.: 'ANY :: raise' pc 208 (life.pir:81) called from Sub 'ROOT_CLASS :: life' pc 1699 (life.pir:656) called from Sub 'ROOT_CLASS :: make' pc 1235 (life.pir:495) called from Sub '_root' pc 71 (life.pir:39) In the future, we should be able to report the HLL line numbers instead of (or in addition to) the PC and PIR counters. I hope this example is useful for the purposes of discussion, and maybe also as sample input data for whoever implements this. I will keep the example updated according to any design decisions that are made. Regards, Roger Browne
