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