String Processing

Dream Standard Library

The Dream Standard Library, stdlib.dream, defines implementations for the following classes:

• Oyd
• Reader
• Writer
• String

The library depends on functions defined in the Dream runtime support library, located in the rtlib folder.

You will need to make the following changes to your semantic checker:

• writeint and readint are now implemented in Dream, rather than an external library. Your semantic checker and code generator no longer needs to deal with writeint and readint on a “special case” basis.
• The Reader and Writer classes make calls to io_read and io_write, which are not implemented in Dream. You must add special case handling for these methods in your semantic checker.
• If your code generator generates method calls using the techniques discussed in class, you shouldn’t need any special case handling to call the Reader_io_read and Writer_io_write implementations in the runtime support library. Simply generate code to call them as if they were “normal” Dream object methods. Both of them expect the implied out and in object that your code generation should automatically push on the stack.

• Your code generator will need to generate appropriate code when visitIdExpr encounters references to out and in.

  Since these are predefined variables (not instance variables, local variables, or parameters), I suggest generating code to define these as global variables, as you did for all variables in Phase 3.

  You will want to instantiate out and in as part of your standard startup code.

String Semantics

Dream has a built-in data type named string. Its implementation is the String class defined in stdlib.dream. This is much like C#, which has a datatype string that is implemented using the .NET System.String class.

In Dream, as in C#, programs can define variables using either the string datatype or the String class. The data type and the class are equivalent and interchangeable. To avoid having to do lots of special-purpose checks throughout your code, I suggest modifying the Type.getTypeForName( ) method to return Type.STRING when given the name “String”.

In your semantic checker, when visiting the String class, you’ll want to associated it with the string Type.

Since you’re not required to implement relational operators or the string concatenation operator, you shouldn’t need to make any other changes to your semantic checker.

String Code Generation

When your compiler encounters a string literal expression, it must generate code to instantiate a string object.

Using the string_fromlit C function in the Dream runtime support library, your compiler might do this:

.data
stringlit26:
  .string "This is some text"

.text
  pushl $stringlit26
  call string_fromlit
  addl $4, %esp
  pushl %eax

Note that it is ok to switch back and forth between .data and .text segments as shown in this example.

Is That It?

Yes! With these small changes to your semantic checker and code generator’s visitStringLit methods, you have (inefficient) string support.