- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Status of Pascal
- Thread starter CP/M User
- Start date
Unsure Ada would have been Influenced by C++ given it came out before C++.[/QUOTE said:Ada is one of the Pascaline languages (Pascal, Delphi, Modula, Oberon, Ada, Prism and, in part, C#) all of which owe their existence to Algol and PL/1 (even perhaps PLM).
This branch of evolution is distinct from the branch of C, C++, Java... all the way to C#. Not everyone knows this, but Microsoft hired the guy behind Delphi to create C# - thus arguably bringing some common sense to this whole language branch at last
I recall that it was TP2.0 that first introduced a purpose to having an 8087 chip on the old IBM 5150 PC and IBM 5160 XT back in 1984: yet another speedup for the really fast executables created with relatively little effort. All just so far ahead of all the others in compiler speed and optimization
Whilst I could also program in C for the IBM platform (I was an embedded systems programmer), I usually just didn't bother! Pascal was just so much easier - ergo more productive.(Incidentally, IBM finally started shipping the 8087 as an option only in 1983 - until then it had largely remained as an unused and ignored socket on the motherboards).
But I agree, TP4 was the first version to start being usable (less stressful to edit). But the real life-changer for me was the mouse support from TP6 onward! It just made my life so much easier for all those long hours of coding.
What a lot of people may not realize now is just how much commercial code was created using TP and later Delphi. As I said before: whilst C programmers whinged about efficiency (I was one) and Ada programmers whined about safety (I was one too), Pascal programmers quietly got on with the task of being productive (yep, that too). And some of us are still there, doing that, today.
I'm still a "user" now (never made it to the clinic) - only this year updated my horribly expensive subscription to Delphi yet again - although it may be for the last time now, as I'm semi-retired.
Trixter
Veteran Member
BP7/TP7 creates the smallest code due to 1. compiler optimizations and 2. the standard libraries being broken up a little bit more, which allows for better smart linking. An example of #1 is when you use with..do, the compiler is smart enough to cache ES:DI for the block (also a speed boost).
How? When I spend hours coding in TP7, I try to never take my hands away from the keyboard. The only thing the mouse stuff is good for is quickly moving windows around, but I rarely do that.
Ruud
Veteran Member
I second that. But nowadays I mainly use FreePascal. FP enables me to reserve a lot of memory already at the definition part: I don't have to allocate it dynamically and, most important, I'm not limited to these 64 KB chunks.
But FP does have it disadvantages: it should support I/O operations in a DOS mode but I never got it working. And a program run under TP7 is about three times as fast as the same program run under FP.
My I/O must be run under a real time OS anyway (simulation of Commodore drives and computers) so here I use TP7 running in the DOS mode of Windows 98 SE. Most of the systems are dual boot: 98SE and XP. I mainly use XP to exchange files with my W7 laptop.
Different strokes for different folks.
I have used Lazerus, although never for anything professional. Whilst I have always found it impressive, given its open-source nature, I'm afraid I'll always regard it as Pepsi to my Coke. But that's just me. (As that really annoying US advert series says: "Because I-Can").
Trixter
Veteran Member
That can't possibly be right. FP is full 32-bit protected mode; the elimination of segment management/math alone is a huge speedup, and dealing with 32-bit dword values is native. All things being equal, 32-bit execution is faster on modern processors than 16-bit execution as Intel has optimized in that direction ever since the Pentium Pro (favoring 32-bit over 16-bit).
If you have a measured example of that behavior, send me a PM, maybe I can figure out what's going on in your code.
CP/M User
Veteran Member
I only recall rotating the Mouse clockwise in TP while typing code with my other hand. :D
I would've only had time to do that during compilation...
I distinctly recall not using the mouse in the IDE. I also seem to remember that many keystrokes from TP4 were changed by TP6 which irritated me. I'm not sure what they were, probably Wordstar style block commands or something.
I distinctly recall not using the mouse in the IDE. I also seem to remember that many keystrokes from TP4 were changed by TP6 which irritated me. I'm not sure what they were, probably Wordstar style block commands or something.
Ruud
Veteran Member
I will look for an example.
Ruud
Veteran Member
Hallo Trixter,
Just my two cents: could it be that handling the files was handled better by TP in those days?
I'm sorry but I think those programs were my assemblers and disassemblers and these have moved FreePascal quite some time ago (10 years?). I clearly understand your arguments but in those days it was a fact. But adding more and more functions and supporting more CPUs the tools didn't only get more memory hungry but I ran against this 64 KB barrier again and again. So at the end I had to switch to FreePascal. But doing so I got another idea: it were multi-pass assemblers. So why not reading the source code into memory the first time and start the disassembly from there? That worked out fine. And two things: FPC improved in time and PCs became faster and faster in time. Source code that took "ages" now are handled in seconds.
Just my two cents: could it be that handling the files was handled better by TP in those days?
Trixter
Veteran Member
It depends on what very early versions of FP were doing. Without seeing your code, there's no way to tell.
For very early versions of FP, and for specific workloads, it is possible 32-bit protected-mode FP programs were slower when it came to heavy I/O via DOS calls. It is also possible that early versions of FP created much larger code that didn't fit inside the L2 cache of your system, whereas TP did. But those would be only two use cases, which isn't enough to make the blanket statement "a program run under TP7 is about three times as fast as the same program run under FP" as you did. For most compute- or memory-hungry workloads, even a suboptimal 32-bit pmode program should drastically outperform a 16-bit real-mode program
Ruud
Veteran Member
Not needed, IMHO. I (still) only use two type of files: TEXT for the source and log files and "file of byte" for the generated binaries. For every pass the lines were read and handled one by one. Three passes handle most type of files but if a weird nesting of variables was used, more passes were added. The binaries were generated after the last pass.
It sounds more than reasonable but... no offense meant or taken but it was what I experienced, I even used my watch to verify numbers. Maybe there were other things that played a role like programs running in the background.
Trixter
Veteran Member
Most likely it was your use of TEXT file types without buffers. FP probably had very basic handling of the TEXT type in the early days; it was likely unbuffered.