Like PASM, any line can start with a label definition like LABEL :, but label definitions can also stand on their own line. PIR code has both local and global labels. Global labels start with an underscore . The name of a global label has to be unique, since it can be called at any point in the program. Local labels start with a letter. A local label is accessible only in the compilation unit where it's defined. (We'll discuss compilation units in the next section.)The name has to be unique there, but it can be reused in a different compilation unit. branch L1 # local label bsr _L2 # global label Labels are most often used in branching instructions and in subroutine calls. 10.4.1 Compilation Units Compilation units in PIR are roughly equivalent to the subroutines or methods of a high-level language. Though they will be explained in more detail later, we introduce them here because all code in a PIR source file must be defined in a compilation unit. The simplest syntax for a PIR compilation unit starts with the .sub directive and ends with the .end directive: .sub _main print "Hello, Polly.\n" end .end This example defines a compilation unit named _main that prints a string. The name is actually a global label for this piece of code. If you generate a PASM file from the PIR code (see the Section 10.2.2 earlier in this chapter), you'll see that the name translates to an ordinary label: _main: print "Hello, Polly.\n" end The first compilation unit in a file is normally executed first, but as in PASM, you can flag any compilation unit as the first one to execute with the @MAIN marker. The convention is to name the first compilation unit _main , but the name isn't critical. .sub _first print "Polly want a cracker?\n" end .end .sub _main @MAIN print "Hello, Polly.\n" end .end This code prints out "Hello, Polly." but not "Polly want a cracker?". Section 10.6 later in this chapter goes into much more detail about compilation units and their uses. |