In the last installment I mentioned that in that part and this one, we would cover the two features that tend to separate the toy language from a real, usable one. We covered procedure calls in that installment. Many of you have been waiting patiently, since August ‘89, for me to drop the other shoe. Well, here it is.
In this installment, we’ll talk about how to deal with different data types. As I did in the last segment, I will NOT incorporate these features directly into the TINY compiler at this time. Instead, I’ll be using the same approach that has worked so well for us in the past: using only fragments of the parser and single-character tokens. As usual, this allows us to get directly to the heart of the matter without having to wade through a lot of unnecessary code. Since the major problems in dealing with multiple types occur in the arithmetic operations, that’s where we’ll concentrate our focus.
A few words of warning: First, there are some types that I will NOT be covering in this installment. Here we will ONLY be talking about the simple, predefined types. We won’t even deal with arrays, pointers or strings in this installment; I’ll be covering them in the next few.
Second, we also will not discuss user-defined types. That will not come until much later, for the simple reason that I still haven’t convinced myself that user-defined types belong in a language named KISS. In later installments, I do intend to cover at least the general concepts of user-defined types, records, etc., just so that the series will be complete. But whether or not they will be included as part of KISS is still an open issue. I am open to comments or suggestions on this question.
Finally, I should warn you: what we are about to do CAN add considerable extra complication to both the parser and the generated code. Handling variables of different types is straightforward enough. The complexity comes in when you add rules about conversion between types. In general, you can make the compiler as simple or as complex as you choose to make it, depending upon the way you define the type-conversion rules. Even if you decide not to allow ANY type conversions (as in Ada, for example) the problem is still there, and is built into the mathematics. When you multiply two short numbers, for example, you can get a long result.
I’ve approached this problem very carefully, in an attempt to Keep It Simple. But we can’t avoid the complexity entirely. As has so often has happened, we end up having to trade code quality against complexity, and as usual I will tend to opt for the simplest approach.
Before diving into the tutorial, I think you’d like to know where we are going from here... especially since it’s been so long since the last installment.
I have not been idle in the meantime. What I’ve been doing is reorganizing the compiler itself into Turbo Units. One of the problems I’ve encountered is that as we’ve covered new areas and thereby added features to the TINY compiler, it’s been getting longer and longer. I realized a couple of installments back that this was causing trouble, and that’s why I’ve gone back to using only compiler fragments for the last installment and this one. The problem is that it just seems dumb to have to reproduce the code for, say, processing boolean exclusive OR’s, when the subject of the discussion is parameter passing.
The obvious way to have our cake and eat it, too, is to break up the compiler into separately compilable modules, and of course the Turbo Unit is an ideal vehicle for doing this. This allows us to hide some fairly complex code (such as the full arithmetic and boolean expression parsing) into a single unit, and just pull it in whenever it’s needed. In that way, the only code I’ll have to reproduce in these installments will be the code that actually relates to the issue under discussion.
I’ve also been toying with Turbo 5.5, which of course includes the Borland object-oriented extensions to Pascal. I haven’t decided whether to make use of these features, for two reasons. First of all, many of you who have been following this series may still not have 5.5, and I certainly don’t want to force anyone to have to go out and buy a new compiler just to complete the series. Secondly, I’m not convinced that the O-O extensions have all that much value for this application. We’ve been having some discussions about that in CompuServe’s CLM forum, and so far we’ve not found any compelling reason to use O-O constructs. This is another of those areas where I could use some feedback from you readers. Anyone want to vote for Turbo 5.5 and O-O?
TINY will support only two data types: The character and the 16-bit integer. I may also try to do something with strings, since without them a compiler would be pretty useless. KISS will support all the usual simple types, including arrays and even floating point.
TINY will only have two control constructs, the IF and the WHILE. KISS will support a very rich set of constructs, including one we haven’t discussed here before... the CASE.
KISS will support separately compilable modules.
One caveat: Since I still don’t know much about 80x86 assembler language, all these compiler modules will still be written to support 68000 code. However, for the programs I plan to upload, all the code generation has been carefully encapsulated into a single unit, so that any enterprising student should be able to easily retarget to any other processor. This task is “left as an exercise for the student”. I’ll make an offer right here and now: For the person who provides us the first robust retarget to 80x86, I will be happy to discuss shared copyrights and royalties from the book that’s upcoming.
But enough talk. Let’s get on with the study of types. As I said earlier, we’ll do this one as we did in the last installment: by performing experiments using single-character tokens.
It should be apparent that, if we’re going to deal with variables of different types, we’re going to need someplace to record what those types are. The obvious vehicle for that is the symbol table, and we’ve already used it that way to distinguish, for example, between local and global variables, and between variables and procedures.
The symbol table structure for single-character tokens is particularly simple, and we’ve used it several times before. To deal with it, we’ll steal some procedures that we’ve used before.
It really doesn’t matter much where you put this procedure... I plan to cluster all the symbol table routines together, so I put mine just after the error reporting procedures.
OK, run this program. You should get a (very fast) printout of all the letters of the alphabet (potential identifiers), each followed by a question mark. Not very exciting, but it’s a start.
Now, run the program again. What did you get?
This time, when you run the program, you should get an output showing that the symbol table is working right.
and run the program again. Did it work? Then we have the symbol table routines needed to support our work on types. In the next section, we’ll actually begin to use them.
Now, in the main program, add a call to TopDecls and run the program. Try allocating a few variables and note the resulting code generated. This is old stuff for you, so the results should look familiar. Note from the code for TopDecls that the program is ended by a terminating period.
While you’re at it, try declaring two variables with the same name, and verify that the parser catches the error.
We can create the code to take care of these declarations with only slight modifications. In the routines below, note that I’ve separated the code generation parts of Alloc from the logic parts. This is in keeping with our desire to encapsulate the machine-dependent part of the compiler.
Make the changes shown to these procedures, and give the thing a try. Use the single characters ‘b’, ‘w’, and ‘l‘ for the keywords (they must be lower case, for now). You will see that in each case, we are allocating the proper storage size. Note from the dumped symbol table that the sizes are also recorded for later use. What later use? Well, that’s the subject of the rest of this installment.
Note that these two routines are strictly code generators; they have no error-checking or other logic. To complete the picture, we need one more layer of software that provides these functions.
to the main program. Thus, after the declaration section is complete, they will be executed to generate code for the loads. You can play around with this, and try different combinations of declarations to see how the errors are handled.
You can test this one the same way as the loads.
There is one small, nagging problem. Before, we used the Pascal terminating period to get us out of procedure TopDecls. This is now the wrong character... it’s used to terminate Block. In previous programs, we’ve used the BEGIN symbol (abbreviated ‘b‘) to get us out. But that is now used as a type symbol.
The solution, while somewhat of a kludge, is easy enough. We’ll use an UPPER CASE ‘B‘ to stand for the BEGIN. So change the character in the WHILE loop within TopDecls, from ‘.‘ to ‘B‘, and everything will be fine.
For each declaration, you should get code generated that allocates storage. For each assignment, you should get code that loads a variable of the correct size, and stores one, also of the correct size.
There’s only one small little problem: The generated code is WRONG!
This code is correct. It will cause the lower eight bits of C to be stored into A, which is a reasonable behaviour. It’s about all we can expect to happen.
This is NOT correct. It will cause the byte variable A to be stored into the lower eight bits of D0. According to the rules for the 68000 processor, the upper 24 bits are unchanged. This means that when we store the entire 32 bits into C, whatever garbage that was in those high bits will also get stored. Not good.
So what we have run into here, early on, is the issue of TYPE CONVERSION, or COERCION.
Before we do anything with variables of different types, even if it’s just to copy them, we have to face up to the issue. It is not the easiest part of a compiler. Most of the bugs I have seen in production compilers have had to do with errors in type conversion for some obscure combination of arguments. As usual, there is a trade-off between compiler complexity and the potential quality of the generated code, and as usual, we will take the path that keeps the compiler simple. I think you’ll find that, with this approach, we can keep the potential complexity in check rather nicely.
Before we get into the details (and potential complexity) of type conversion, I’d like you to see that there is one super-simple way to solve the problem: simply promote every variable to a long integer when we load it!
In this case, the CLR turns out not to be necessary, since the result is going into a byte-sized variable. With a little bit of work, we can do better. Still, this is not bad, and it typical of the kinds of inefficiencies that we’ve seen before in simple-minded compilers.
With this version, a byte is treated as unsigned (as in Pascal and C), while a word is treated as signed.
As we’ve seen, promoting every variable to long while it’s in memory solves the problem, but it can hardly be called efficient, and probably wouldn’t be acceptable even for those of us who claim be unconcerned about efficiency. It will mean that all arithmetic operations will be done to 32-bit accuracy, which will DOUBLE the run time for most operations, and make it even worse for multiplication and division. For those operations, we would need to call subroutines to do them, even if the data were byte or word types. The whole thing is sort of a cop-out, too, since it ducks all the real issues.
OK, so that solution’s no good. Is there still a relatively easy way to get data conversion? Can we still Keep It Simple?
Yes, indeed. All we have to do is to make the conversion at the other end... that is, we convert on the way OUT, when the data is stored, rather than on the way in.
But, remember, the storage part of the assignment is pretty much independent of the data load, which is taken care of by procedure Expression. In general the expression may be arbitrarily complex, so how can procedure Assignment know what type of data is left in register D0?
Again, the answer is simple: We’ll just ASK procedure Expression! The answer can be returned as a function value.
Note that Load is a function, which not only emits the code for a load, but also returns the variable type. In this way, we always know what type of data we are dealing with. When we execute a Store, we pass it the current type of the variable in D0 ‘’(AX for I8086)’‘. Since Store also knows the type of the destination variable, it can convert as necessary.
Again, note how incredibly simple these two routines are. We’ve encapsulated all the type logic into Load and Store, and the trick of passing the type around makes the rest of the work extremely easy. Of course, all of this is for our special, trivial case of Expression. Naturally, for the general case it will have to get more complex. But you’re looking now at the FINAL version of procedure Assignment!
All this seems like a very simple and clean solution, and it is indeed. Compile this program and run the same test cases as before. You will see that all types of data are converted properly, and there are few if any wasted instructions. Only the byte-to-long conversion uses two instructions where one would do, and we could easily modify Convert to handle this case, too.
Sharp-eyed readers might have noticed, though, that we don’t even have a proper form of a simple factor yet, because we don’t allow for loading literal constants, only variables. Let’s fix that now.
Now, when dealing with literal data, we have one little small problem. With variables, we know what type things should be because they’ve been declared to be that type. We have no such type information for literals. When the programmer says, “-1”, does that mean a byte, word, or longword version? We have no clue. The obvious thing to do would be to use the largest type possible, i.e. a longword. But that’s a bad idea, because when we get to more complex expressions, we’ll find that it will cause every expression involving literals to be promoted to long, as well.
OK, compile this code into your program and give it a try. You’ll see that it now works for either variables or constants as valid expressions.
If you’ve been following this series from the beginning, I’m sure you know what’s coming next: We’ll expand the form for an expression to handle first additive expressions, then multiplicative, then general expressions with parentheses.
The nice part is that we already have a pattern for dealing with these more complex expressions. All we have to do is to make sure that all the procedures called by Expression (Term, Factor, etc.) always return a type identifier. If we do that, the program structure gets changed hardly at all.
Note in this routine how each procedure call has become a function call, and how the local variable Typ gets updated at each pass.
Note also the new call to a function UnOp, which lets us deal with a leading unary minus. This change is not necessary... we could still use a form more like what we’ve done before. I’ve chosen to introduce UnOp as a separate routine because it will make it easier, later, to produce somewhat better code than we’ve been doing. In other words, I’m looking ahead to optimization issues.
The simplicity is deceptive, though, because what we’ve done is to defer all the logic to PopAdd and PopSub, which are no longer just code generation routines. They must also now take care of the type conversions required.
And just what conversion is that? Simple: Both arguments must be of the same size, and the result is also of that size. The smaller of the two arguments must be “promoted” to the size of the larger one.
But this presents a bit of a problem. If the argument to be promoted is the second argument (i.e. in the primary register D0), we are in great shape. If it’s not, however, we’re in a fix: we can’t change the size of the information that’s already been pushed onto the stack.
The solution is simple but a little painful: We must abandon that lovely “pop the data and do something with it” instructions thoughtfully provided by Motorola.
After all the build-up, the final results are almost anticlimactic. Once again, you can see that the logic is quite simple. All the two routines do is to pop the top-of-stack into D7, force the two operands to be the same size, and then generate the code.
OK, I grant you: I’ve thrown a lot of routines at you since we last tested the code. But you have to admit that each new routine is pretty simple and transparent. If you (like me) don’t like to test so many new routines at once, that’s OK. You can stub out routines like Convert, Promote, and SameType, since they don’t read any inputs. You won’t get the correct code, of course, but things should work. Then flesh them out one at a time.
When testing the program, don’t forget that you first have to declare some variables, and then start the “body” of the program with an upper-case ‘B‘ (for BEGIN). You should find that the parser will handle any additive expressions. Once all the conversion routines are in, you should see that the correct code is generated, with type conversions inserted where necessary. Try mixing up variables of different sizes, and also literals. Make sure that everything’s working properly. As usual, it’s a good idea to try some erroneous expressions and see how the compiler handles them.
At this point, you may think I’ve pretty much gone off the deep end in terms of deeply nested procedures. There is admittedly a lot of overhead here. But there’s a method in my madness. As in the case of UnOp, I’m looking ahead to the time when we’re going to want better code generation. The way the code is organized, we can achieve this without major modifications to the program. For example, in cases where the value pushed onto the stack does NOT have to be converted, it’s still better to use the “pop and add” instruction. If we choose to test for such cases, we can embed the extra tests into PopAdd and PopSub without changing anything else much.
These routines parallel the additive ones almost exactly. As before, the complexity is encapsulated within PopMul and PopDiv. If you’d like to test the program before we get into that, you can build dummy versions of them, similar to PopAdd and PopSub. Again, the code won’t be correct at this point, but the parser should handle expressions of arbitrary complexity.
Once you’ve convinced yourself that the parser itself is working properly, we need to figure out what it will take to generate the right code. This is where things begin to get a little sticky, because the rules are more complex.
The type of the product is typically not the same as that of the two operands. For the product of two words, we get a longword result.
The 68000 (and x86) does not support a 32 x 32 multiply, so a call to a software routine is needed. This routine will become part of the run-time library.
It also does not support an 8 x 8 multiply, so all byte operands must be promoted to words.
This table shows the actions to be taken for each combination of operand types. There are three things to note: First, we assume a library routine MUL32 which performs a 32 x 32 multiply, leaving a >> 32-bit << (not 64-bit) product. If there is any overflow in the process, we choose to ignore it and return only the lower 32 bits.
As you can see, the routine starts off just like PopAdd. The two arguments are forced to the same type. The two calls to Convert take care of the case where both operands are bytes. The data themselves are promoted to words, but the routine remembers the type so as to assign the correct type to the result. Finally, we call one of the two code generator routines, and then assign the result type. Not too complicated, really.
At this point, I suggest that you go ahead and test the program. Try all combinations of operand sizes.
If you don’t believe it, try dividing any large 32-bit number (meaning that it has non-zero bits in the upper 16 bits) by the integer 1. You are guaranteed to get an overflow exception.
The problem is that the instruction really requires that the resulting quotient fit into a 16-bit result. This won’t happen UNLESS the divisor is sufficiently large. When any number is divided by unity, the quotient will of course be the same as the dividend, which had better fit into a 16-bit word.
Since the beginning of time (well, computers, anyway), CPU architects have provided this little gotcha in the division circuitry. It provides a certain amount of symmetry in things, since it is sort of the inverse of the way a multiply works. But since unity is a perfectly valid (and rather common) number to use as a divisor, the division as implemented in hardware needs some help from us programmers.
The type of the quotient must always be the same as that of the dividend. It is independent of the divisor.
In spite of the fact that the CPU supports a longword dividend, the hardware-provided instruction can only be trusted for byte and word dividends. For longword dividends, we need another library routine that can return a long result.
Note that we assume that DIV32 leaves the (longword) result in D0.
OK, install the new procedures for division. At this point you should be able to generate code for any kind of arithmetic expression. Give it a whirl!
At last, in this installment, we’ve learned how to deal with variables (and literals) of different types. As you can see, it hasn’t been too tough. In fact, in some ways most of the code looks even simpler than it does in earlier programs. Only the multiplication and division operators require a little thinking and planning.
The main concept that made things easy was that of converting procedures such as Expression into functions that return the type of the result. Once this was done, we were able to retain the same general structure of the compiler.
I won’t pretend that we’ve covered every single aspect of the issue. I conveniently ignored unsigned arithmetic. From what we’ve done, I think you can see that to include them adds no new challenges, just extra possibilities to test for.
I’ve also ignored the logical operators And, Or, etc. It turns out that these are pretty easy to handle. All the logical operators are bitwise operations, so they are symmetric and therefore work in the same fashion as PopAdd. There is one difference, however: if it is necessary to extend the word length for a logical variable, the extension should be done as an UNSIGNED number. Floating point numbers, again, are straightforward to handle... just a few more procedures to be added to the run-time library, or perhaps instructions for a math chip.
Perhaps more importantly, I have also skirted the issue of type CHECKING, as opposed to conversion. In other words, we’ve allowed for operations between variables of all combinations of types. In general this will not be true... certainly you don’t want to add an integer, for example, to a string. Most languages also don’t allow you to mix up character and integer variables.
Again, there are really no new issues to be addressed in this case. We are already checking the types of the two operands... much of this checking get done in procedures like SameType. It’s pretty straightforward to include a call to an error handler, if the types of the two operands are incompatible.
In the general case, we can think of every single operator as being handled by a different procedure, depending upon the type of the two operands. This is straightforward, though tedious, to implement simply by implementing a jump table with the operand types as indices. In Pascal, the equivalent operation would involve nested Case statements. Some of the called procedures could then be simple error routines, while others could effect whatever kind of conversion we need. As more types are added, the number of procedures goes up by a square-law rule, but that’s still not an unreasonably large number of procedures.
What we’ve done here is to collapse such a jump table into far fewer procedures, simply by making use of symmetry and other simplifying rules.
The answer depends on what kind of language you want, and the way you’d like it to behave. What we have not addressed is the issue of when to allow and when to deny the use of operations involving different data types. In other words, what should be the SEMANTICS of our compiler? Do we want automatic type conversion for all cases, for some cases, or not at all?
Let’s pause here to think about this a bit more. To do so, it will help to look at a bit of history.
FORTRAN II supported only two simple data types: Integer and Real. It allowed implicit type conversion between real and integer types during assignment, but not within expressions. All data items (including literal constants) on the right-hand side of an assignment statement had to be of the same type. That made things pretty easy... much simpler than what we’ve had to do here.
This was changed in FORTRAN IV to support “mixed-mode” arithmetic. If an expression had any real data items in it, they were all converted to reals and the expression itself was real. To round out the picture, functions were provided to explicitly convert from one type to the other, so that you could force an expression to end up as either type.
This led to two things: code that was easier to write, and code that was less efficient. That’s because sloppy programmers would write expressions with simple constants like 0 and 1 in them, which the compiler would dutifully compile to convert at execution time. Still, the system worked pretty well, which would tend to indicate that implicit type conversion is a Good Thing.
C is also a weakly typed language, though it supports a larger number of types. C won’t complain if you try to add a character to an integer, for example. Partly, this is helped by the C convention of promoting every char to integer when it is loaded, or passed through a parameter list. This simplifies the conversions quite a bit. In fact, in subset C compilers that don’t support long or float types, we end up back where we were in our earlier, simple-minded first try: every variable has the same representation, once loaded into a register. Makes life pretty easy!
The ultimate language in the direction of automatic type conversion is PL/I. This language supports a large number of data types, and you can mix them all freely. If the implicit conversions of FORTRAN seemed good, then those of PL/I should have been Heaven, but it turned out to be more like Hell! The problem was that with so many data types, there had to be a large number of different conversions, AND a correspondingly large number of rules about how mixed operands should be converted. These rules became so complex that no one could remember what they were! A lot of the errors in PL/I programs had to do with unexpected and unwanted type conversions. Too much of a Good Thing can be bad for you!
Pascal, on the other hand, is a language which is “strongly typed,” which means that in general you can’t mix types, even if they differ only in NAME, and yet have the same base type! Niklaus Wirth made Pascal strongly typed to help keep programmers out of trouble, and the restrictions have indeed saved many a programmer from himself, because the compiler kept him from doing something dumb. Better to find the bug in compilation rather than the debug phase. The same restrictions can also cause frustration when you really WANT to mix types, and they tend to drive an ex-C-programmer up the wall.
Even so, Pascal does permit some implicit conversions. You can assign an integer to a real value. You can also mix integer and real types in expressions of type Real. The integers will be automatically coerced to real, just as in FORTRAN (and with the same hidden cost in run-time overhead).
In the spirit of strong typing, Pascal will not allow you to mix Char and Integer variables, without applying the explicit coercion functions Chr and Ord.
Turbo Pascal also includes the types Byte, Word, and LongInt. The first two are basically the same as unsigned integers. In Turbo, these can be freely intermixed with variables of type Integer, and Turbo will automatically handle the conversion. There are run-time checks, though, to keep you from overflowing or otherwise getting the wrong answer. Note that you still can’t mix Byte and Char types, even though they are stored internally in the same representation.
The ultimate in a strongly-typed language is Ada, which allows NO implicit type conversions at all, and also will not allow mixed-mode arithmetic. Jean Ichbiah’s position is that conversions cost execution time, and you shouldn’t be allowed to build in such cost in a hidden manner. By forcing the programmer to explicitly request a type conversion, you make it more apparent that there could be a cost involved.
I have been using another strongly-typed language, a delightful little language called Whimsical, by John Spray. Although Whimsical is intended as a systems programming language, it also requires explicit conversion EVERY time. There are NEVER any automatic conversions, even the ones supported by Pascal.
This approach does have certain advantages: The compiler never has to guess what to do: the programmer always tells it precisely what he wants. As a result, there tends to be a more nearly one-to-one correspondence between source code and compiled code, and John’s compiler produces VERY tight code.
On the other hand, I sometimes find the explicit conversions to be a pain. If I want, for example, to add one to a character, or AND it with a mask, there are a lot of conversions to make. If I get it wrong, the only error message is “Types are not compatible.” As it happens, John’s particular implementation of the language in his compiler doesn’t tell you exactly WHICH types are not compatible... it only tells you which LINE the error is in.
I must admit that most of my errors with this compiler tend to be errors of this type, and I’ve spent a lot of time with the Whimsical compiler, trying to figure out just WHERE in the line I’ve offended it. The only real way to fix the error is to keep trying things until something works.
So what should we do in TINY and KISS? For the first one, I have the answer: TINY will support only the types Char and Integer, and we’ll use the C trick of promoting Chars to Integers internally. That means that the TINY compiler will be MUCH simpler than what we’ve already done. Type conversion in expressions is sort of moot, since none will be required! Since longwords will not be supported, we also won’t need the MUL32 and DIV32 run-time routines, nor the logic to figure out when to call them. I LIKE it!
KISS, on the other hand, will support the type Long.
Should it support both signed and unsigned arithmetic? For the sake of simplicity I’d rather not. It does add quite a bit to the complexity of type conversions. Even Niklaus Wirth has eliminated unsigned (Cardinal) numbers from his new language Oberon, with the argument that 32-bit integers should be long enough for anybody, in either case.
But KISS is supposed to be a systems programming language, which means that we should be able to do whatever operations that can be done in assembler. Since the 68000 supports both flavours of integers, I guess KISS should, also. We’ve seen that logical operations need to be able to extend integers in an unsigned fashion, so the unsigned conversion procedures are required in any case.
That wraps up our session on type conversions. Sorry you had to wait so long for it, but hope you feel that it was worth the wait.
In the next few installments, we’ll extend the simple types to include arrays and pointers, and we’ll have a look at what to do about strings. That should pretty well wrap up the mainstream part of the series. After that, I’ll give you the new versions of the TINY and KISS compilers, and then we’ll start to look at optimization issues.