Notes From TML To LSP

By Thomas Scheiderich, Interez Travel Reservation Systems

For a while it seemed if you wanted to do any programming in Pascal on the Mac, you must either bear the cost of a Macintosh and a Lisa to do any serious programming, or you could always use MacPascal. Neither was an acceptable solution. Those with larger bank accounts could afford two machines but that was unacceptable for most of us. MacPascal was also unthinkable since it does not generate compiled code, but like most interpreters it is easier to develop code than the compile/link method.

Enter TML Pascal. When TML came onto the scene about a year ago, there were nothing but raves about the product. I was ecstatic when I started using it myself. The only capability that seemed to be missing was the ability to compile and link separate units. For many of us this was not a problem, as it was promised in a further release. So we all continued to develop our programs, and except for the units problem continued to rave about the program. How can you put down a product that measures up to equivalent compilers (C, Forth and Fortran) that cost three, four and five times as much. But as our programs got larger, compile times got longer and there was still no units capability. Four or five changes and compiles could take an hour or more.

Wouldn't it be nice to have the capabilities of both TML and MacPascal to do our development! And LightSpeed Pascal comes as close to this as I believe you are likely to see. I found I was developing code in hours that would have taken me days or weeks to do under TML.

This is not a review of LightSpeed Pascal, but an impression of the program I have from having used both TML and LightSpeed. I will be showing you some of the differences between the two development systems and some of the problems I encountered in my experience with the new program. It is important to note that these tests are run on a old 512K Mac with the old Roms and 400K drives.

First of all, for those of you who are currently using TML and wish to convert to LightSpeed, you will find the conversion very easy. The first step is to change the compiler directives. In your TML source you may have some lines similar to the following:

{$I MemTypes.ipas  }
{$I QuickDraw.ipas }
{$I OSIntf.ipas    }
{$I ToolIntf.ipas  }
{$I PackIntf.ipas  }
{$a+}
{$L  Grow/Rsrc }

These lines need to be removed and replaced with

{$I-}
{$R-}

The first line "{$I-}" tells the compiler that you don't want LightSpeed to do automatic initialization. You should always put this in your code or else the program may work when running in project mode and may not work when the code is converted into an application. The second line "{$R-}" tells the compiler you want range checking off. This is only necessary if you have this line in your TML code or you don't have the range checking option defined at all. This is because LightSpeed defaults to range checking on and TML defaults to range checking off. If you have range checking off in TML and range checking on in LightSpeed, code that worked under TML may not work under LightSpeed.

Second, if you are using a resource file, you must remove the ".REL" extension from the ".R." file and change it to anything else so that RMaker does not compile the resource file in REL format. LightSpeed suggests ".RSRC", but in actuality any extension or no extension will do. You must declare something, however, or RMaker won't compile the file. Then you run RMaker to create the new resource file. Next you must tell LightSpeed about the resource file by selecting "Run Options" from the Project menu. When the dialog box appears, check the resource box and choose the resource file to use (if you haven't converted the resource file from the REL format, the file won't appear).

Third, if you have your comments on multiple lines surrounded by only two curly braces you will get an error. For example:

{this comment section
must be changed}

which works in TML, must be changed to

{this comment section}
{must be changed}

for the code to work in LightSpeed.

This was all that was necessary to get my old TML code running under LightSpeed. My program is a terminal emulator for a Data General which uses multiple windows (text and drawing) and does file transfers. It currently is about 1200 lines long. I used this program for my testing and also the famous Sieve program to do comparisons between the two compilers.

The relative speeds and sizes are compared in the following tables. As can be seen from the tables, the application programs are larger (about 2k) in the LightSpeed versions. I talked to the LightSpeed people about this and apparently the program does a certain amount of routine stripping to keep the application to a reasonable size. The TML stripping linker is a little better (my application was 14K under TML version 1.0 and 8K under 1.1). Routines you reference may cause LightSpeed to pull in related routines even if they aren't used. This is apparently a tradeoff for speed. 2K seems to be close to the maximum difference between from TML and LightSpeed as can be seen from the graphs and tables.

The development speeds reflect the time it takes to make changes and and execute the programs. As can be seen you can make a change and test it in less than a minute (about 30 seconds if not saving the text). In TML this would take about 5 minutes - five to ten times longer.

The Sieve program has been used in benchmarks of other compilers and I decided to use it to compare these two. The code I used was:

PROCEDURE EXECUTE_SIEVE;
 CONST
 SIZE = 8190;
 VAR
 FLAGS : ARRAY[0..SIZE] OF BOOLEAN;
 I, PRIME, K, COUNT, ITER : INTEGER;
 TEXTSTRING : STR255;
 BEGIN
 GOTOXY(10, 10);
 DRAWSTRING('10 ITERATIONS. PRESS MOUSE WHEN READY TO GO!');
 REPEAT
 UNTIL BUTTON;
 FOR ITER := 1 TO 50 DO    {THIS IS USUALLY 1 TO 10}
 BEGIN
 COUNT := 0;
 FOR I := 0 TO SIZE DO
 FLAGS[I] := TRUE;
 FOR I := 0 TO SIZE DO
 IF FLAGS[I] THEN
 BEGIN
 PRIME := i + i + 3;
 {gotoxy(10, 12);}
 {ERASE_LINE(12, 10, 10);}
 {numtostring(prime, textstring);}
 {DRAWSTRING(TEXTSTRING);}
 k := i + prime;
 WHILE k <= size DO
 BEGIN
 flags[k] := false;
 k := k + prime;
 END;
 count := count + 1;
 END;
 END;
 gotoxy(10, 14);
 ERASE_LINE(14, 10, 15);
 numtostring(count, textstring);
 drawstring(textstring);
 gotoxy(15, 14);
 drawstring('primes');
 END;

It was rather interesting that if you display the prime numbers as they are found, TML seems a little faster and when the numbers aren't displayed LightSpeed seems a little faster. It seems that LightSpeed's computations are a little better but TML's handling of QuickDraw may be a little faster.

I would liked to have compared the units capability of the two compilers, except as of this writing, it was not available on TML. It is now released as version 2.0.

Some notes on LightSpeed:

Type cohersion cannot always be done within a procedure or a function statement. According to LightSpeed the rule is: if the variable in the procedure is a "var" parameter you cannot use type cohersion; if not a "var", you can. They say it is a high priority to make this more like Lisa Pascal by removing this restriction.

You cannot get the assembler source like you can in TML. This may be a problem if you want to optimize a piece of code. This is apparently not a high priority item with them. It would also be a little more difficult to do, according to them, because the compilation doesn't go through the normal "compile to assembler source" and then assemble that code. They go directly from Pascal source to machine code.

Segmentation is handled differently. LSP requires segmentation at unit boundaries, while TML allows the segment option to be placed directly in the code. Also, LSP uses all the space in the first segment for it's libraries so that your main program must be limited to about 5K in the first segment, with everything else in units placed in the second segment. Yet when the application is built, your program may fit entirely within segment one. Thus our 14K program required two segments with only a 5K main in segment one.

LSP also does not have objects and LS is moving slow on this. TML on the other hand supports objects in 2.0.

All in all, I was very impressed with the product and had no problems with it, once I found out about the range checking, REL resource and curly brackets differences. I think there is going to be less of a demand for MPW with this around.