All Databases MacTech Vol 12-1996

Dec 96 Factory Floor

Volume Number: 12

Issue Number: 12

Column Tag: From The Factory Floor

Marcel Achim, Pascal Reanimator

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.

Referenced by (2):