Marcel Achim, Pascal Reanimator

By Dave Mark, ©1996 by Metrowerks, Inc., all rights reserved.

This month’s Factory Floor interview is with Marcel Achim, the heart and soul of Metrowerks Pascal efforts. As Neil never tires of reminding me, Pascal is alive and well and, in one publisher’s opinion, still a wonderful language.

Dave: How did you hook up with Metrowerks?

Marcel: I was recruited on the university campus by the then VP of Research who was teaching there. I became involved in an underway project, the development of a Modula-2 compiler running on various UNIX boxes built on MIPS chips. That was my introduction to the fascinating world of compilation. I started by writing library code and translating interfaces from C to Modula-2, then I moved on to porting the compiler to the different vendor boxes, figuring out their idiosyncrasies.

Dave: Were you doing this work in Pascal? If not, when did you bring Pascal and Metrowerks together?

Marcel: The MIPS compilers used a frontend/backend architecture with the backend being proprietary which caused some problems. That led to our need to develop a compiler technology where we could hold rights both on the frontend and backend. At the same time we started another project on the Macintosh to provide a Pascal compiler along with tutorial and teaching material for Macmillan. That compiler was built around the Modula-2 package available then. So the new technology was meant to provide a solution for multiple frontends and multiple backends, and was supposed to be the replacement for these versions of Pascal and Modula-2. The chosen architecture was a derivative from the Oberon architecture developed in Zurich by Nicklaus Wirth’s team and was first targeted to the SPARC platform. I then implemented Pascal and Modula-2 on SPARC using that architecture. We then stopped the development of UNIX compilers and I inherited the Macintosh compilers where I unified the Pascal and Modula-2 code generators. Around this time it was decided that we needed a C compiler, the PowerPC was in the air and we received in the mail a terrific demo from Andreas. [To hear more about Andreas’s story, check back a few issues for the interview with Andreas Hommel.]

Dave: How did the Pascal compiler make the leap to CodeWarrior?

Marcel: At this point, we had a 68K C compiler with optimizations, a split frontend/backend design. Pascal is very strong in the developer community (still today FileMaker Pro is mostly written in Pascal and is built with CodeWarrior). CodeWarrior alone would only be Metrowerks C and wouldn’t provide the broader industrial completeness and strength that we wanted to provide. So we dropped the architecture used on the SPARC, which still didn’t support optimizations, and I got the Pascal frontend development plus backend/linker modifications, interfaces, libraries and utilities. DR/1 was to ship in January with the scheduled launch of the first Power Macintoshes. In the mean time, I dropped my Masters and stopped teaching. I was giving lectures at the university for the past few months along with working on my Masters and working part-time on Metrowerks compilers.

MPW Pascal was the chosen dialect because it’s the de facto standard Pascal dialect on Macintosh. THINK Pascal wasn’t supported and relates heavily to MPW Pascal except for a few minor differences. The biggest problem involved in developing CodeWarrior Pascal was the universal interfaces. Since Apple decided not to support Pascal anymore, the new interfaces developed for the introduction of the PowerPC were made, keeping the PowerPC calling conventions in mind and making use of C’s syntactic capabilities (for example, the CONST keyword is meant to specify an invariant pointer parameter and doesn’t have a Pascal equivalent).

The change from 68K to PPC calling conventions was dramatic for Pascal as the passing of value records and arrays are not the same. There were two possibilities: either support the 68K calling conventions on the PowerPC (thus breaking the calling conventions adopted for all languages, which were inherited from IBM’s AIX machines and provide a seamless common way of doing cross-language, cross-vendor routine calls) or modify the interfaces to render the expected parameter passing. The 68K conventions pass every record and array bigger than 4 bytes by passing a pointer. The PowerPC passes value records into registers and on the stack, and all arrays by pointer regardless of the size. To be able to match both PowerPC and 68K conventions with the same set of interfaces could have been achieved by using a new parameter passing method using the CONST keyword that would have the semantics of a value parameter and an efficient passing implementation. This solution wasn’t taken because it would have broken some compilers. The retained solution was to use VAR parameters because they force the use of pointers, but it has the drawback of breaking some user code, especially in the case of packed arrays and records.

The other problem encountered on the PowerPC is the signatures. They are packed arrays of 4 chars, so they’d have to be passed by pointer. But their C equivalent is an unsigned long, thus value not pointers. To get this to work I had to introduce on PowerPC an UNSIGNEDLONG data type that’s compatible with packed arrays of 4 chars so OSTYPE can be used without problems. After 2 years of use, this solution to the Universal Interfaces problem has proven to be the right one. Another conclusion that comes up is the need to add a procedural data type to Pascal. The new data type enables the compiler to do type checking on the callback routines that get passed either to user code or the toolbox. This type checking capability has proven to be very effective in the porting of code from 68K to PowerPC.

Dave: So at this point, we have the first CodeWarrior IDE with Pascal and C/C++. Since plugins weren’t introduced till CW6/7, how did the Pascal compiler work?

Marcel: The first releases of CodeWarrior didn’t used the plugins architecture but a common IDE was always in the air as the cornerstone of CodeWarrior. The new PowerPC machines had more resources and made such a design more interesting for an entire IDE. So along with the C/C++ compiler, the Pascal compiler was compiled and linked along with the IDE sources. It wasn’t that the Macintoshes were too slow or the resources poor, it was just that it wasn’t the way to do things. People knew about their machine constraints and didn’t go for blue sky, so the applications were kind of in scale with the hardware capabilities. Now that we have faster and bigger machines it is possible to add on facilities to the programs and these added facilities eat up not only disk space but also memory. So having the ability to load on demand various parts of a program has been around almost as long as computers. It’s the way of doing it that changes over time and across platforms.

Dave: Can You talk about the difference between the C++ “value model” and Object Pascal’s “reference” model?

Marcel: The object model is the underlying runtime model that affects the aspect and behavior of objects. In Object Pascal the object model used is known as the reference model because you have to explicitly invoke the creation and deletion of objects. On the other hand, C++ and Turbo Pascal use the value model which involves far more complex semantics for manipulating objects. People often mix method binding with the object model. This accounts for some misconceptions. In Object Pascal, the language only allows compile time binding determination for ‘inherited’ method calls. All the other methods can be overridden, thus forcing late binding which can be changed by a clever linker for monomorphic methods (methods that are never overridden within the program).

In C++, member functions need the ‘virtual’ keyword to specify polymorphism, thus helping the compiler decide how to perform the method call. (It gets more complicated when multiple inheritance is involved.) This binding facility is partially lifted by the introduction of procedural types in CodeWarrior Pascal, but still has to be hand constructed along with the data fields when the object gets created. The difference between object models comes to light when you look at the copy semantics. In Object Pascal, assigning one object to another, passing it as a value parameter or returning one as a function result doesn’t create a new instance as in C++ (and associated copy constructors) or as in Turbo Pascal (bug prone object casting), but only copies a reference. In Object Pascal cloning an object requires a method call and is explicit. This greatly simplifies the complexity of the program without limiting the functionality.

Dave: What are some of the differences between CodeWarrior Object Pascal and other dialects of Object Pascal?

Marcel: There are as many Pascal dialects as there are vendors. One of the biggest contenders is Turbo Pascal. The differences can be categorized into three fields; runtime support (mostly IO and platform specific stuff), the enhanced syntax, and finally the class and object models. We’ve already discussed the object model. The most apparent IO difference between Object Pascal and Turbo Pascal is TP’s assign routine, which binds a logical file to a physical file. Under Object Pascal this is performed directly by the opening routines.

The other IO differences lie in file access semantics, mostly for the handling of binary files. The original Pascal’s (and also the ANS standard) way of dealing with them is using get/put and direct file access thru the caret operator ‘file^’. The object support is very different. OP implements a very simple syntax that hasn’t evolved in about 10 years, whereas TP went through a constant evolution of their implementation. This is clearly an area where we have to expand OP’s capabilities because it really represents an advantage to programmers to have a more flexible implementation.

Dave: What are you working on now?

Marcel: My group is currently working on a Windows version of CodeWarrior Pascal. We are also developing a tool that will automate the use of C precompiled headers within Pascal as Pascal support is more and more lacking within Apple and nonexistent on Windows.

Dave: What do see in the future for yourself and for Pascal?

Marcel: I think in the near future we’re going to see some kind of reevaluation of project development using C/C++ as metrics, and studies are going to circulate. I think that there could be some kind of backlash toward Pascal and Ada if the figures show that C/C++ didn’t deliver the expected results. As far as Pascal goes, from the market share perspectives, Pascal is a player in the academic market as most attempts to move to C and C++ didn’t work very well.

On the other hand, in software engineering things are different. Pascal would have to evolve much faster to meet today’s software engineering needs and standardize on a wide variety of platforms. Even then I’m not too sure about the prospects. As for me, I’m linked to Pascal as I want to evolve CodeWarrior’s implementation of Object Pascal to be a player in both the Macintosh and Windows Pascal market.