On 7/8/2022 4:26 PM, Rugxulo wrote:

Turbo Pascal debuted in 1983 with support for CP/M and DOS via .COM
files (max. 64k size). When they dropped CP/M and .COM support in TP 4
(1987), then they were able to use separate "units" and DOS .EXEs for
larger code. (But TP 3 could still address 1 MB with the heap.) There
were other complications, too.
Not quite sure what you are trying to say here.

Anders Hejlsberg  deliberately designed Compas Pascal/Poly Pascal (which was renamed to Turbo Pascal 1.0 on CP/M, then ported from Z80 assembler to x86 for CP/M-86 and DOS) as a 1-pass compiler, with minimal memory usage and also forgoing any real linking process, just combining each and every program with the same, complete run time library and just adding the actual program code behind that for the rest of the available memory.

He took the general idea of the UCSD Pascal menu for the new "IDE" (the predecessor of Compas Pascal, Blue Label Pascal, was just a command line compiler, but with the same concept of creating the resulting executable without link, just appending to the standard RTL) but because of the deliberate decision of the compiling process, there was no ""room" for including a modular concept.

Once Turbo Pascal reached v3, there was no further room to improvement, and hence it was decided to re-write the compiler for version 4. At that point, Hejlsberg made the decision to introduce the unit concept of UCSD Pascal, and as the goal was to produce native x86 code, dropped the .COM format and produced .EXE files, which lend themselves nicely to the unit concept. However, in order to allow for smart-linking, the units would not be compiled to .obj (which had no provision for the info of the interface section) but produced proprietary .TPU (Turbo Pascal Unit) files. That move was also more aided by the speed improvements in PCs CPUs rather than the available memory.

And as CP/M, in either form, was obsolete and got dumped, using memory mapped video output became a viable option (the early versions of Turbo Pascal could actually be used though a serial terminal still!), someone else at Borland (it wasn't Hejlsberg himself) came up with the full screen, windowed text UI IDE, which was pretty much unchanged (just adapted) used for the simultaneously released Turbo C 1.0.

Turbo Pascal 5.0 then (re) introduced overlays, 5.5 first steps in object oriented programming and an integrated debugger, while 6.0 introduced real inline assembler (instead of inline() with inserting byte wise opcodes of assembly routines) and a vastly improved debugger.

Byte magazine (issue Dec. 1986) has a comparison of four Pascal
compilers. Modula-2 (with modules) was no stranger as their Aug. 1984
issue covered it extensively. But of those four Pascal compilers (MS,
UCSD, Prospero, MetaWare, with sidenote for TP 3):

64K-byte code/data limit? no, no, no, no, yes
Chaining? no, yes, yes, no, yes
Export abstract data types? no, no, no, yes, no
Modules? yes, no, no, yes, no
External routines? yes, yes, yes, yes, yes
Include files? yes, yes, yes, yes, yes
Overlays? yes, no, yes, yes, yes
Segmentation? no, yes, yes, yes, no
unit libraries? yes, yes, no, no, no

Keep in mind the obvious fact that TP compiles/links in about 2
seconds that which takes about a minute (60 secs.) on most other
compilers. Plus, TP was $70 (while most others, besides $100 UCSD,
were roughly $300, $400, or $600).
As for the speed, see my explanation above. Beside that, there are some errors in this list. Never used Prospero Pascal, but I did use Metaware Professional Pascal and UCSD Pascal, beside Turbo Pascal 3.0 (and Digital Research Pascal MT+ 86, and a little bit of Microsoft Pascal). Completely false for example is that UCSD would not have modules, as mentioned before, they are the ones that "invented" the unit concept. Also, there was a general overlay system common to all p-System compilers (beside Pascal, there was FORTRAN as well as a rather elusive BASIC compiler). And without looking at that article, I am not sure how/why they differentiate between modules and "unit libraries"...

There's a different article (same Dec. 1986 issue) about something
else entirely ("approximating integrals") that has unstructured BASIC
(GWBASIC??) code as an example. It's weird seeing so many competing
languages. There's even an ad for MS QuickBASIC compiler 2.0 bragging
about speed, EGA support, structured constructs (no GOTO required),
and "reusable modules" for $100.

My point is that everything "new" was getting obsoleted by everything
"newer" and then some. Things moved too fast, but progress was
definitely happening.

Well, that "progress" unfortunately might not always for a real world benefit. A lot of newer programming languages and programming paradigms do not really help solving real world (end user) problems. And a lot of "competing" languages was rather a good thing, as it helped to show which ones provided an actual benefit. That's why things like Prolog for example never really caught on (same as Lisp or Smalltalk). Others just didn't get the right marketing (for example Comal, which could have been a "better BASIC"). And a lot of those languages had certain strong sides, which made them more suitable for one specific area of applications. Today, a lot of programmers are pretty much "one trick ponies", they just know one thing , and try to use that for everything, even if there would be better suited alternatives. (Looking at you Javascript! ;-) ) In a world where the only tool you know is a hammer, everything starts to look like a nail. Just the other day I improved a clients proprietary application for certain (rather frequent) operations by several 1000% speed wise, by eliminating the use of a SQL server by a rather simple in-memory data structure and simple read, write, insert and search functions. Whoever wrote the original parts was just throwing SQL at every "database" problem, even if more efficient solutions should have been obvious.


Ralf



_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to