A few months back, Microsoft invite a bunch of us computer press types to an all-day shindig so they could tell us about the high-performance languages. They even gave us all sweatshirts so we could prove we were there (I use mine to sleep in, subliminal messages being what they are).
During one of those sessions, a presenter made the interesting comment. "We had things in the works for Pascal until somebody else came along and took the market away" he said. Given the main topics of the seminar, it seemed clear at the time, that Microsoft had abandoned the PC-based Pascal market to this unnamed "somebody else." It also seemed clear that they had chosen to dig their trenches around C and Basic. But now things are not so "clear," because the biggest name in little computer software has released its own Pascal 4.0.
The version level numbers are pure coincidence. These numbers will be short-lived anyway, since Borland is about to introduce Turbo Pascal 5.0. Borland's version of Turbo Pascal will have a debugger and thus go head-to-head with Microsoft's Pascal 4.0 Codeview connection, which in turn will trigger some newer and better thing from Microsoft, and so on, and so forth. You know how that goes.
Anyway, this month's column examines the new Microsoft Pascal. Some good news and bad news will be shared along with some comparisons to Turbo Pascal 4.0. Then we'll talk about another 4.0, about which there's only bad news: the new LIM EMS standard.
The first thing that hits you about Microsoft Pascal 4.0 is the quantity of the documentation---a 3-inch pile of paper. This documentation consists of the standard User's Guide and Reference Guide (little has changed, if anything at all, from the previous version) plus a Version 4.0 Update of 68 pages. Additionally, the documentation includes two Codeview manuals (the basic book and an update), plus a guide to the new Microsoft Editor.
That should give you an idea of the major enhancements in Microsoft Pascal 4.0: Codeview and the editor. Less obvious, but equally significant, are an upgrade to the large memory model (the only model now available), full-scale support for Windows development, and an OS/2 option.
One of the great disappointments about these documents is Appendix C of the Reference Guide, which discusses the differences between Microsoft and "other Pascals." What other Pascals? UCSD, for crying out loud. Give me a break! Who are these guys trying to kid? If Microsoft wants back a piece of the Pascal action, they won't get it by pretending that Turbo doesn't exist.
Another great disappointment about the manuals is that Microsoft still hasn't put related information all in one place nor indexed the information in an intuitive manner. Seldom can you simply look up something in the Microsoft Pascal docs; it's a sort of scavenger hunt with hints cleverly concealed by the indexer. The new manuals are no improvement over the old. In fact, the new documentation compounds the problem because you must now hunt through six manuals, compared to the earlier two. For example, it took me more than an hour to find out how to get a program into the symbolic format Codeview expects.
The compiler package runs on a DOS machine, but it can act as a cross-compiler for OS/2 development. An installation option lets you set up the system for OS/2 protected mode, OS/2 real mode plus DOS, or both. Link-time directives specify in which environment the executable runs. This is one area where Microsoft has a decided edge over Turbo, which hasn't yet heard of OS/2.
You can run this development system on a dual-floppy machine if you have masochistic tendencies. The manuals assume that you do, which I suppose is valid as a worst-case treatment. In that event, you'll have to swap diskettes in the A: drive three times to compile and link. A hard disk is so strongly recommended that it is almost mandatory.
Compilation is a two-step process with an optional third pass. The first two steps (PAS1 and PAS2) compile and optimize the source code into object form. The third step (called PAS3) produces an object code listing with numbered lines and a symbol table. The results are then linked to produce an .EXE file. The package comes with the latest segmented overlay linker (Version 5.01), plus an OS/2 linker called BIND.
Pass 1 of the compiler has a dozen command-line switches, each with a corresponding metacommand that can be embedded in the source file. In case of conflict between the command line and a metacommand, the metacommand wins. Most of these are pragmas for various check routines-subscript ranges, dereferencing of NIL pointers, stack overflow, and so forth. Some also pertain to the generation of debugger information in the .EXE file. For a change, the user manual lists these metacommands on one page in Table 52) and gives the defaults (all off). The other passes don't have switches, but the linker has nine. (All explained in Table 6.2.)
The 80X86 limits a segment size to 64K, which is the upward bound on any given code segment generated by the compiler/linker. The solution is to develop modular programs, compile them separately, and link them to form large applications. Each module then occupies its own code segment, thus allowing the program to transcend the 64K limit on individual segments. A routine in one segment can call a subprogram in another, so long as the external subroutine is declared PUBLIC in its owning module and EXTERN in the caller's; the result corresponds to a far proc in assembly language.
Microsoft Pascal's implementation of units is superior to that of Turbo Pascal 4.0. The Microsoft concept more closely parallels Modula-2 (from which it was borrowed). In Microsoft Pascal a unit consists of two separate files, the Interface and the implementation, and a mechanism exists for explicitly exporting identifiers. In Turbo, a unit is one file that consists of both parts, and everything in the Interface section is implicitly exported. The Microsoft approach more readily allows the implementation to be hidden from the caller, which is desirable in group projects and commercial packages.
The data segment of a Microsoft Pascal program is also limited to 64K. This segment contains all global variables, memory resident constants, the default heap, and (gulp!) the stack. Including the stack in the data segment is a bad design decision on the part of Microsoft, because a heavily recursive program with a lot of data can easily run out of stack space and have a nervous breakdown. Turbo does it better, with an entirely separate stack segment that can be up to 64K.
On the other hand, Microsoft offers more flexibility with heap allocations. You can use the default (near) heap within the data segment, or the long heap located in all the uncommitted memory of the system. The only heap in Turbo is the long one, which can cause problems when one program spawns another. Microsoft provides a plethora of mechanisms for dealing with the two heaps.
At the aforementioned press briefing, Microsoft made a big deal out of its optimization, so I thought it might be instructive to test for it. One of the things Microsoft compilers purportedly do is to move invariant computations outside of loops. Here's a simplistic example:
In other words, y and z need not be recalculated in each loop, since their values don't deviate from one iteration to the next. Optimization is supposed to place these calculations outside the loop.
Well, guess what? Microsoft Pascal doesn't optimize for this condition, regardless what Microsoft says. I wrote a little program with this kind of construct inside the loop, and then moved it outside. Here are the results:
With invariant calculations inside: 0.98 seconds
With invariant calculations outside: 0.44 seconds
Turbo doesn't claim to optimize for this, and their results for the same program versions were 1.10 and 0.49 seconds, respectively.
While on the topic of performance comparisons, I translated three of the standard Berkeley benchmarks from C into Pascal and ran them under both Microsoft and Turbo. The benchmarks are as follows:
Execution times for the benchmarks on an 8-MHz AT clone with no-wait state memory were as follows:
In other words, Microsoft does substantially better at sieve, and the other two benchmarks are somewhat of a wash. A comparison of code sizes reveals some startling differences:
If the Microsoft compiler is so optimizing, why does it generate 10.5 times as much code on average to do the same job as the compiler from Borland?
It happens that I make a living from nine to five as a software engineer in a big Unix house. I know from personal experience that you can optimize a compiler to recognize the standard benchmarks and to perform superlatively when it thinks its results have a chance of being published. This is optimization for the wrong reasons, inasmuch as benchmarks are synthetic programs that don't necessarily parallel real-world programs.
Suspecting that Borland might be guilty as charged, I wrote another program outside the realm of the standard benches. This one is SINES.PAS, which took 1000 sines on my AT clone (without a math coprocessor). Here are the results:
The upshot of this exercise is that Borland's minimally optimizing compiler is either very smart indeed, or else it really does outperform Microsoft's by a 2-to-1 in timing and a 6-to-1 size ratio for a floating-point emulation application. So much for Microsoft's optimization.
Besides OS/2 support, the Microsoft compiler offers a couple of things that the Turbo compiler does not---Codeview and Windows. Codeview is a superlative debugger for .EXE files. It lets you set breakpoints and watchpoints, step through source lines and see where a program is going awry because of a runaway loop or whatever, monitor the stack, and so on. Maybe I'm old-fashioned; I still prefer to stick WRITELN statements into a misbehaving program to find out what's going on, but I make an exception where it comes to Codeview. It's great, and the ability to control debugging through three different means makes it the most intuitive debugger around. One of these days, we'll stack Codeview up against the soon-to-be announced Borland debugger and see how they compare. Meanwhile, Codeview wins the day.
Microsoft claims that its C and Pascal 4.0 are the only languages that support Windows. That's not entirely true. For example, Actor is an object-oriented language for AI and Windows, which is Microsoft-approved. Although Actor is not a mainstream language, it does negates the assertion. Certainly the mainstream Turbo languages don't work with Windows; I struggled to write a Windows application in Turbo C and the program just wouldn't compile, despite help from Borland.
You could make the waggish observation that Microsoft's near-sole support is a commentary on the acceptance (or rather lack thereof) of Windows within the programming community. Nevertheless, the advent of OS/2 Presentation Manager---a glorified Windows---makes this unwieldy software the user interface of the future. For those who want to get a head start on that future, Microsoft Pascal 4.0 is an attractive alternative to the more arcane C language. Microsoft Pascal is the native language of Windows, which enforces the Pascal calling convention on C programmers who want to use its interface. Version 4.0 provides full access to the richness of the Windows environment by means of the WINDOWS.INC include file and the $WINDOWS metacommand.
Microsoft Pascal is purely a highlevel language. Some of the intrinsic functions and procedures coat specific DOS calls with syntactic sugar. The language does lack general-purpose, low-level calls comparable to Turbo's MsDos and Intr procedures. Also, no direct access is provided to registers from Microsoft Pascal. If you want to do low-level stuff such as generating software interrupts, you have to write subprograms in assembly language and link them as externals with the Pascal program. This makes it necessary for serious developers to have an assembler (and guess who just happens to sell the best-known of them). It also complicates the development process. Microsoft hasn't been reluctant to extend the language in other areas, and they would have done their Pas cal users a great service by providing low-level calls and register access directly from the source level.
On the other hand, none of the major software manufacturers has its mixed language act together as well as Microsoft. You can link Pascal modules not only with assembly-language routines, but also with c and Fortran modules. Just as Microsoft C has an attribute for specifying the Pascal calling convention, Pascal also has a C-convention option. These modifiers govern the order in which parameters are physically passed to subprograms. Also, Pascal offers a VARYING attribute that allows Pascal programs to imitate C in passing a variable number of arguments to a subroutine.
Microsoft also has the advantage over Turbo in the areas of object portability and linkage. The Turbo linker is indistinguishable from the compiler and limited because it allows only the importing of assembly-language routines and the most rudimentary C routines. You can't export a Turbo Pascal object module because no such thing exists. Also, Turbo doesn't support any overlays. The Microsoft linker is a separate program altogether, supporting mix-and-match of object modules coming from various languages and furnishing extensive support of overlays. Thus you can create programs in which each module is written in the language best suited for its task; Fortran for computations, assembler for low-level access and speed; Pascal for record processing; and C for control. The linker then joins them into a program in which little-used sections can operate as overlays. Pretty impressive stuff.
Also impressive is the new Microsoft editor, a welcome addition to the programmer's toolkit, which comes with Pascal 4.0. It's a windowing environment (though not a Windows application) that allows you to view and work on multiple source files, or different parts of the same file, in bordered text windows. The editor includes all the features you'd expect from an advanced program development tool. In effect, the editor creates a work environment much like Quick and Turbo, but more extensive because of windowing, a clipboard, and word-processing-like operations. It includes compile-link-and-go without leaving the editor.
In default mode the editor bears a visual and operational resemblance to Brief. The Microsoft editor is infinitely customizable with macros and provides the ability to assign the macros to keys. You can also write C routines and install them as editor functions. A control file called TOOLS.INI stores your configuration as ASCII text strings, which you can edit at will. The editor also comes with preconfigured files that make it emulate the Brief and Epsilon editors, the Quick environment, and Wordstar.
Will the new Pascal release win back the market for Microsoft? Probably not. It's harder to use than Turbo, doesn't offer as many extensions, takes much longer from source to executable, produces .EXE files that are unnecessarily large, and costs three times as much. For medium to light-heavyweight development, the only thing I can think of that makes Microsoft Pascal 4.0 preferable to Turbo 4.0 is Codeview.
On the other hand, Microsoft has now elevated Pascal into the same league with its venerated C and Fortran compilers for true heavyweight systems development. Especially strong are its support for Windows, OS/2, and mixed-language programming. These features are bound to win back some share of the Pascal market and to attract others who find C too esoteric for their tastes.
I had a terrific idea for this month's column. Four months after I ordered it on an emergency basis, Intel finally sent my LIM 4.0 upgrade kit. I thought I'd write a column about using the new EMS standard for interprocess communication. This made sense, since the focus of this month's issue is real-time programming, which implies multiple processes, that often need to communicate among themselves, right? Well, guess what. The upgrade kit didn't work.
My problems started with the first page of the slender leaflet. It said: trust me, all your problems are solved if you just run the INSTALL program. Uh-huh. Half a dozen panels into the program, the instructions tell you to please wait for the one second to several minutes required to find out how much memory you have. It was late, so I let the program survey all the world's memory while I showered. Then I rebooted, restarted INSTALL, and waited a while longer. Then I rerebooted and re-restarted INSTALL, after that I went to bed. In the morning, it was still trying to quantity my paltry 1 Mbyte of EMS.
Since that failed, I tried to understand the gobbledygook on pages 3 through 10 of the upgrade instructions. The instructions purport to tell you how to manually install the upgrade. Trouble is, it's written in tongues. I speak nine languages fluently, and one of them is computerese, but my eyes glazed by page 4. In short, I couldn't get LIM 4.0 up and running, so I reviewed Microsoft Pascal 4.0 instead.
I griped about the LIM 4.0 problem among my computer buddies, and they all clucked and shook their heads. "A bunch of junk" was the consensus. Then Ron Copeland of DDJ relayed a rumor to the effect that LIM 4.0 is incompatible with the VGA, which I have on my AT. I discussed it over lunch with Tyler Sperry, who was still trying to recover from my original vitriolic attack on Intel. At his suggestion, I pulled my VGA and reinstalled the EGA from which I had upgraded shortly before.
Hey, suddenly it worked! Intel's INSTALL ran without a hitch. Whoopee, now I have more EMS capability and a lesser graphics board. Is the trade-off worth it? I don't think so. I shouldn't have to make that trade-off, nor should you.
It's no secret. If you look at the "Examining Room" column in this magazine, or in numerous other magazines, you will notice that I do a lot of product reviews. I don't like to be tough on little guys. They labor hard in their garages and there's much blood, sweat, and hope in what they produce. I have empathy with the little guys; I'm one of 'em. A lot of us are.
But Intel isn't a bunch of guys in a garage. They're a big outfit, and they ought to know better than to release this kind of flawed stuff. Months late, I might add.
I know how EMS works. I just wrote a chapter on it for my forthcoming book on advanced programming in Turbo C. EMS needs a 64K frame buffer in high memory, and it just so happens that VGA hogs a lot of memory exactly where EMS wants it.
So what we have here is a conflict of standards: VGA vs EMS 4.0. That's not my fault and I resent---on behalf of us all---having to make a choice between better memory management and better graphics. The way VGA works is hardly proprietary information. The two standards converge on one vendor, whose initials are IBM, which owns a substantial investment in Intel, who is the object of this diatribe.
One could make a case that EMS was here first, and thus owns a legitimate stake in some unclaimed piece of high memory. On the other hand, VGA is hardware, which is by definition inflexible, whereas the EMS frame buffer is determined by a software device driver. The software ought to be smart enough to figure out how to coexist with VGA.
That it isn't is a discredit to all those Big Guys who allegedly have our best interests at heart. They screwed up, plain and simple, and it's you and I who have to pay the price for their inattention.
Looking at MS-Pascal 4.0
FOR w := 1 to 100 DO BEGIN
x := w + 10; {loop-variant}
y:= 12; {invariant}
z:= (y*13)DIV7; {invariant}
END;sieve Tests array indexing and integer arithmetic
fib Tests recursion
acker Tests recursion and integer arithmetic
Turbo Microsoft
sieve 40.97 31.36
fib 22.68 24.34
acker 12.36 12.58
Turbo Microsoft
sieve 2128 27,501
fib 2064 19,267
acker 2096 19,283
Time Size
Microsoft 5.12 19,413
Turbo 2.60 3,248
And Now For LIM 4.0