Class 28: Translating control structures

Held Friday, November 13, 1998

Notes

• I've brought back gifts from the conference. Claim one if you want one. If not, I'll find other takers.
• Next Monday, at noon, our own Ryan Gerling will speak on Integrating Old Technologies with New: Automating a Paper Reporting System.
  • Learn about the wonders of doing internships for government contractors!
  • Discover whether it's possible to do computer science and software engineering without writing any code!
  • Ask yourself whether these blurbs have anything to do with Ryan's talk.
• As you might expect, I have not yet had a chance to grade the makeup exams. I will try to do so this weekend.
• We'll continue on chapter seven. Please read chapter eight for next week.
  • You may be noting that we're generating somewhat strange code; chapter eight will have suggestions on cleaning it up.
• This month, Friday the 13th falls on a Friday. Be prepared for different luck.
• So, how are those type-checkers going?

Simple Structures

Strings

• What do we do about strings?
• It's likely that we'll need to treat string variables as references to strings stored elsewhere in memory.
• We'll need to find a way to handle the length of strings.
  • We can put a ``null terminator'' at the end of the string.
  • We can put a ``string length'' at the beginning of the string.
• We note that there are three kinds of strings:
  • ``constant'' strings that are used in the program as in

    str = "hello"
    

  • string variables
  • constructed strings
• Constant strings will need to be stored in static memory (hence the MEM operation).
• Constructed strings will need to be stored in dynamic memory.
• String functions will often be ``built in''.

Digression: l-values and r-values

• In many languages, there is some conflict/confusion between the name of a container and the contents of the container.
• For example, if you've stored the value 3 in the container named X, what does it mean when you see "X"? Does it mean "the container" or "the value". It often depends on the context.
• If the name appears as something to be assigned to, it typically means "the container". Most typically, this is when it appears on the left-hand-side of an assignment.
• If the name appears as a value to be assigned, it typically means "the value". Typically, this happens when the variable appears on the right-hand-side of an assignment.
• To help clarify matters, language researchers often refer to the l-value (container) and r-value (contents) of a variable.
• This makes it easier to describe assignment. For example, if X and Y are integer variables, "X gets Y" means "Store the r-value of Y in the container corresponding to the l-value of X".
• However, our choice of whether to use l- or r-values may depend on the types of X and Y. What if each is
  • A container for basic values.
  • A container for references to containers for basic values.
  • A container for references to containers for rereferences to basic values.
• Yes, there are languages that let you be that specific about types.
• If we don't know the types of X and Y in "X gets Y", what are some possible meanings?
  • Place the r-value of Y in the container given by the l-value of X.
  • Place the l-value of Y in the container given by the l-value of X.
  • Place the r-value of Y in the container given by the r-value of X?
• Note also that different names are used differently. For example, constants are also named, but you usually don't want to give programmers access to l-values of constants.

Declarations

• While it may have seemed that we don't need to return anything when we translate declarations, we really do.
  • Variable declarations construct code to assign to the newly declared variables.
  • Function declarations construct code for the body of the function (although that code need not be returned).
• Assignment should be done by copying.
• Function declarations can be translated as other code, except for dealing with parameters and return values, which should be handled by the Frame module.

Control structures

• We're now ready for a different aspect of translation: control structures.

Conditionals

• There are two issues in conditionals: how you translate the condition expression and how you translate the selection of where to go
  • They are somewhat related, as the condition may have many ``short circuit'' branches to other parts
  • The current ASTs help with the process, since they ``pre-translate'' And and Or to If.
• In translating a conditional statement, you will typically generate three labels:
  • one for the true part
  • one for the (possibly empty) false part
  • one for the end of the statement
• At the end of the code for the true part, you add an unconditional branch to the end of the statement
• At the end of the code for the false part, you do the same
• When translating an And, you branch based on the first part of the And. If it's true, you do the second part of the And. If the first part is false, you branch to the false label.
• When translating an Or, you again branch based on the first part of the Or. If the first part is true, you branch to the true label. If the first part is false, you branch to the second half of the Or.
• Appel seems to suggest filling in the labels later, but it's relatively easy to pass the labels along.
• For example, using Appel's strategy, we might write

  translate(IfExp(int pos, Abs.Exp test, Abs.Exp texp, Abs.Exp fexp)) =
    Label tlab = new Label();
    Label flab = new Label();
    Label endlab = new Label();
    Tree.Exp cond = translate(test);
    Tree.Exp tcode = translate(texp);
    Tree.Exp fcode = translate(fexp);
    return SEQ(cond.cx(tlab,flab),
           SEQ(Label(tlab),
           SEQ(tcode,
           SEQ(JUMP(Name endlab), ExpList(endlab, null),
           SEQ(Label(flab),
           SEQ(fcode,
           SEQ(JUMP(Name endlab), ExpList(endlab, null),
           SEQ(Label(endlab)
              ))))))))
  

• Why the ``extra'' branch to end? It helps us rearrange the code later.

History

• Created Monday, November 2, 1998 as a blank outline.
• On Wednesday, November 4, 1998, added some section headings (taken from Monday's(!) outline).
• On Friday, November 13, filled in the body.
• On Monday, November 16, moved some stuff to the next outline.