Assignment 3, Solved

Part of the homework for 22C:50, Summer 2003
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

 

Homework 3

  1. Correct the BNF given in the header comments for parse_operand
    /* parse one operand of the form
          ::=  |  | .
                 |  (  )
          ::=  { (+|-|&||)  }
       and return its value.
    */
    

    Parenthesized expressions had been left out of the list of legal terms!

  2. Hand assemble this EAL code
    EAL V2.0 by Douglas W. Jones; Mon Jun 30 11:58:22 2003
    
         1             |; The following code just illustrates some features of EAL
         2             |A = .
         3             |. = B
         4 0002: 0000  |  W A
         5             |. = A
         6 0000: 0002  |  W B
         7             |B = .
    

  3. Using the two-pass model of assembly, hand assemble this bit of EAL code that uses conditional assembly:
    EAL V2.0 by Douglas W. Jones; Mon Jun 30 12:00:34 2003
    
         1             |IF 1-DEF(A)
         2             |  . = 1
         3             |ENDIF
         4 0000: 0003  |  W A
         5             |A:
         6 0002: 0002  |  W A
    

    Note that I substituted 1-DEF(A) for UND(A) in the above so I could test this under the EAL assembler, version 2.0 (the one that solves MP2). Note that A was 3 during pass 1 and 2 after its definition in pass 2.

  4. The previous example includes what is called a phase error, where a label gets a different definition on pass 1 than it had on pass 2. Suggest a way to detect and report phase errors. Does your solution also detect and report multiple label definitions (where the same identifier is used as a label in two or more places in the program).

    There are two ways I can think of:

    First, with each definition of a label, if it is already defined (which it should always be during pass 2), complain if the new definition is not identical to the original. This will catch phase errors and also multiple label definitions.

    Second, make a copy of the location counter at the end of pass 1 and compare it with the value of the location counter at the end of pass 2 to verify that pass 1 and pass 2 had the same net effect on the location counter. This will not catch multiple label definitions, nor will it catch some phase errors in programs that set the location counter many times.

  5. There are two ways of supporting multi-character operators such as <<. The lexical analyzer can handle these as two-character punctuation marks, reporting < and << as different lexemes, or the parser can use look-ahead to distinguish between < when it is followed by < and < when it is followed by anything else.

    Propose an experiment you could do, as a programmer, to find out whether << is a distinct lexeme or whether it is two lexemes that are collapsed into one operator at the syntactic level. Do this experiment for some C or C++ compiler and report the result.

    Compile this little program under your C or C++ compiler:

    main() { int a = 1 < < 1; }

    If << was treated as 2 consecutive lexemes, spaces would be allowed between them, as in the above little program. When I tried to compile this, the compiler complained about the second < so the << mark must be one lexeme.

    If your compiler doesn't show context for the error, but only shows line numbers, break the above example into one line per lexeme and your compiler will give you an error number for the line holding the lexeme that got it confused.