Internals of a Turbo Pascal Compiler
turbopascal.org
turbopascal.org
Borland's Turbo Pascal compiler was written in 16-bit x86 assembly, mostly by Anders Hejlsberg.
There is an explanation of this on the front page of the site, but it's not clear from the headline.
(I used to work at Borland on the Delphi compiler, and had access to the source of tpc.exe.)
I went from the necessity of A86 assembler, thru the desperation of GW-Basic .. finally finding Turbo Pascal, which was a revelation at the time, just this phenomenal product and superb piece of engineering.
Pulldown text menus, draggable text windows, editor out of the box .. fast compilation, wow - to me its one of the great monuments of computer history. I feel intensely nostalgic looking back on it now.
And their manuals were first rate.. classy all round.
Be glad you had that one. The other BASICs of those times where much more limited! GW was a little bit of awesome in it's own way. Oh, and POKE and PEEK.
I stuck with TP through version 5, and even convinced my college teachers to let me use it for my programming assignments rather than whatever was on the college mainframe.
The manuals were indeed a huge asset. You didn't really need to know anything about the OS, or go digging for third party documentation online, which was important because there was no online.
That and Ralf Brown's Interrupt List, so I could do something useful.
I stopped with TP5. At that point, I was up to my ears in my thesis project, and was not going to change any of my tools. Plus I'm a real tightwad. By the time I finally finished my degree, got a new job, and a new computer, it was an Apple Mac. And the modern OS's kind of killed my interest in programming for a while.
Good times. In particular, I remember having to implement my own strings, because for a text adventure you often want to have access to strings longer than 255 characters...
Sadly, I never managed to make the jump from writing console applications with TP to writing proper Mac GUI apps. But "Inside Macintosh" cost an absolute fortune at the time (for a 10 year-old kid at any rate), so I ended up scraping enough money together to buy another text book whose name escapes me. I must have read the first few chapters about a million times - they talked about handles and graphics ports etc, but I could never get any code from them to run in TP (I think they were assuming that you would be using MPW?).
Which brings me to the point of this long rambling message - did TP really support graphics programming on the Mac? I know my version of TP was an official bought copy, so we had the manual, but I don't remember ever seeing anything that explained GUI programming in there.
With that one, you could surely do graphics programming on the Mac.
As for Turbo Pascal itself, I wasn't aware it was available on the Mac as well.
IIRC TP was just a quick port & had a very short life on the mac.
The Commodore 128 also offered CP/M compatibility (through a second CPU...), though rarely used.
The Apple II has an optional Z80 card, but the total price was not for everyone, at least in Europe.
Amstrad also sold far less than C128. The whole Amstrad CPC line sold about 3 million vs 5 million C128's. I don't know the breakdown between the Amstrad CPC models, but I'd bet a substantial percentage of that was the 464.
I'm sure the Amstrads were more common for CP/M, though. Of the few people I knew with C128's, most used it as a glorified C64, and nobody used the CP/M mode.
(Incidentally you could also get CP/M support for C64 through a cartridge that housed a Z80...)
On CPC6128 the disk drive was standard (and yes, it was that strange 3" variant, not using the 3.5" disks that would later be known as the "3D model of the save icon".)
"It can compile any source code compatible with Turbo Pascal 7 syntax. It will generate the same executable file and unit files as the original Borland compiler."
Turbo Pascal was a much smaller language than what Delphi became, so I can't point you out examples off the top of my head. If I were looking into compatibility issues, I'd play around with things like alignment and packing rules, TP's various hacks to get around Standard Pascal's fixed length strings (e.g. OpenString {$P+}), etc.
Interestingly, in 3.0, it will support compiling JVM byte code. [1]
[1] http://wiki.freepascal.org/FPC_New_Features_3.0#Support_for_...
https://en.wikipedia.org/wiki/Turbo_Pascal#CP.2FM_and_DOS_ve...
The Turbo Pascal compiler was based on the Blue Label Pascal compiler originally produced for the NasSys cassette-based operating system of the Nascom microcomputer in 1981 by Anders Hejlsberg. Borland licensed Hejlsberg's "PolyPascal" compiler core (Poly Data was the name of Hejlsberg's company in Denmark), and added the user interface and editor. Anders Hejlsberg joined the company as an employee and was the architect for all versions of the Turbo Pascal compiler and the first three versions of Borland Delphi.
The final step in November 1983 - Turbo Pascal v1.0 is created for Borland International, Inc. Distributed on a single floppy disk, Turbo Pascal integrated the Pascal compiler, Wordstar-like text editor, runtime library, run in memory, and creation of .COM programs - all within 131,297 bytes in the TURBO.COM file. The whole product was 33k bytes in size and ran in 64k bytes of memory. The product was delivered for CP/M-80 (Z/80, 5.25 and 8 inch floppy disks), CP/M-86, and MS-DOS/PC-DOS.
BEGIN WRITE('Hi'); END.
hit Ctrl-X and use R to run it.
I started programming with Turbo Pascal pretty much (if one doesn't count a small bit of BASIC before). I also have a vivid memory of Delphi, both programming in Delphi (which was a breeze) and reverse engineering programs written in Delphi (which was a nightmare).
When I got to learn C, already had Turbo Pascal 3, 4, 5.5 and 6.0 on my toolbox.
Compared with Turbo Pascal, the only thing C had going for it was being available in other systems. Everything else was meh.
No memory safe handling, no bounds checking, no units (modules), no namespacing, no proper strings, no OOP support, arrays decaying into pointers, no type safe enumerations, no sets, no generic array indexes...
At least C++ allowed me to get some of those Turbo Pascal features back.
About the question you didn't specifically ask: There's no reason (apart from optional stuff, like array bounds checking) that a Pascal compiler couldn't produce code of equivalent speed as a C compiler. (There is one language with a potential speed advantage over Pascal/C/equivalents and that's Fortran.)
Everyone praises C compiler quality nowadays. On those home computers, C, Pascal and Modula-2 were good enough for general purpose applications, if one wanted real speed, Assembly was the only way to go.
Turbo Pascal, as well as any other Pascal dialects, had the same capabilities to access hardware as C offered.
Also the MS-DOS game development scene and the demo scene tools were heavily based in Turbo Pascal, besides the usual Assembly stuff.
Man I hated reading or figuring out other's Assembly code and Turbo Pascal was a dream in comparison (And Fortran also)
Seeing disassembled code like that kept me from learning C for years...
First it was shitty C code in the 90s, and now the Java language. At least I'm not totally burned out on Javascript yet :-)
What's the market do? Push all effort into C and C++. Results of that are still with us. (sighs) Go and Rust give me some hope in that they're first mainstream languages that solve some problems. On non-mainstream, Julia is an awesome development that might be re-applied to systems programming. Not to mention Racket's metaprogramming combined with C or assembler generation for a high-level use of low-level, fast language. Ivory language does that with Haskell, for example.
So, not as Worse as usual. Still true overall.
Not to mention the amount of money spent writing band aids for them., in form of static and memory analysers and more recently CPU instructions (Intel MPX).
Which not everyone uses, because either it isn't available on their platform, or they choose not to use them anyway.
Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler.
" because either it isn't available on their platform"
I tried to solve that with my tools (lang X) using X-to-C compiler w/ seemless FFI for 3rd party code. Encouraged other languages to do that with many having done it before I got on the scene: Modula, Oberon, Ada, LISP/Scheme, and so on. Let them use good language with hardware/OS of choosing. Ignored it as you said.
"Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler."
David Thornley brought this up on Schneier's blog when he said he was distrusting about those who mentioned "C/C++" as if they're same thing. That using modern C++ prevents many C issues if it's used correctly. Now, I abandoned C++ as anything but a compiler target after all the 90's empirical evaluations showed it was garbage. I think my critique that it lets you shoot yourself in foot easily and is hard to analyse probably still applies like it did when I cited them together. It's why I do.
Nonetheless, I honestly don't know how modern C++ developers code when they're doing it "right" with style guides, newer language features, peer review, etc. I think it would be fair in these discussions to do some new, empirical studies comparing proper C++ to Free Pascal, Go, Rust, Ada, etc in various attributes like was done in 90's. Critical that it's used as pro's say it should be so as not to mislead readers about effectiveness (i.e. C++ used like C didn't work). You know any resources I could use to catch up on topic that capture most or all of how pro's do C++ with modern features? Not necessarily most recent standard but what has been used at least past 5 years maybe 10.
- type safe enums (enum class)
- STL collections instead of plain C like types
- references for out parameters
- RAII
- smart pointers
- values types over heap allocations everywhere
- warnings as errors
The problem is making sure there aren't some guys in the team doing C style coding.
Nowadays C++ is still my language to go when I need to step out of Java and .NET.
The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code.
Effective Modern C++, Tour of C++, Elements of Programming and From Mathematics to Generic Programming are all good books, where safe modern C++ is used.
Thanks for the summary and references. Will be helpful if another honest language comparison is done of C++ against safe, systems languages. Or C++ developers against others on realistic, example programs.
"The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code."
It makes sense. My solution was a auto-generating that from a better language and wrapping their libraries. That does take some serious tooling support, though.
https://www.gnu.org/fun/jokes/unix-hoax.html
Even a professional and fan of C once admitted that this was great because it could've been true. Ain't that something. ;)
So much programming machismo:
* Bounds checking is a little slower, so safeties off!
* Multiprocessing with explicit IPC is slightly slower than thread pools, so safeties off!
* Parameters and explicit return values to functions are a little slower than DATA-DIVISION / instance variable mutation whack-a-mole code, so safeties off!
Funny part is they say this even when alternative languages or libraries implement safety tricks without a performance penalty. Then we see clearly that their resistence isn't technical. ;)
And that big fat stack of manuals you got with Borland Pascal (which I recall buying used for perhaps equiv of $60 in 1993 - same price as the used 2400 bps modem).
However given the nature of Windows APIs, I eventually moved into Turbo C++ for Windows, also with OWL.
Never used the VCL, by then I was already fully into C++.
Then came the experience with Smalltalk, Oberon, Caml, Prolog and many others.
Sadly never had a reason to invest into Delphi.
Delphi really paid my bills as a newbie commercial programmer. That was around the time when the internet took off, and I wrote my first CGI servers in Pascal to make dynamic websites. The Pascal/Delphi language and environment were incredibly versatile and you could write some really fast code with it.
Fond memories. In many ways, TP leveled me up as a programmer.
The Amiga did make its own dent in the universe: http://www.geek.com/games/cgi-first-introduced-to-tv-in-baby...
The secret to the PC's success was not just the clone market, but the open architecture that permitted endless permutations on interexchangable components: motherboards, graphics cards, hard drives, etc. were all pluggable.
Amiga's custom chipset and architecture gave it a huge edge (mostly in multimedia), but the tight coupling made it an evolutionary dead end. Even if they licensed the OS and opened the architecture to clones, the hardware dependency wouldn't have been able to follow suit.
IIRC correctly, TP used a yellow font (well ascii) on a black background (default)? Didn't it also have some quick key combinations (I recall a ctrl+k for some reason but I'm sure it's just memory...)
Only Turbo Pascal 3.0, afterwards the IDE had other colors.
Turbo C always had the more complex IDE, which Turbo Pascal didn't get until 4.0: http://imgur.com/kYjwuPA
That environment used the Turbo Vision library, and it was later ported to DJGPP and also Linux, there's an editor called RHIDE which uses it.
Microsoft used their own IDE in products like QBasic, edit.com, as well as their C and Pascal compilers: http://imgur.com/H6J12Dy
Turbo Pascal 4.0 through 5.5's IDEs were, TTBOMK, not based on Turbo Vision.
Exactly. So-called WordStar combinations, which lot of the editors of the time were using. AFAIK, it is still used on some quite popular text editors on Linux (joe?).
"jstar" version of JOE has the WordStar keys.
I loved Pascal and wrote a race management program for my local sailing club when I was 16. Fond memories. The whole experience was a voyage of discovery, as I had to write my own "windows" style UI using ASCII codes.
I used Delphi later on in university along with Modular2, and C++. I never felt the same passion for these languages as I had had for Turbo Pascal.
I later moved on to VB and VBscript, and didn't like them at all but they paid the bills.
The next time I felt that same type of passion was for C#. Somehow it just clicked. I think it is about what you can achieve productively with the language, as well as the language itself.
He is really a prolific language designer, one of the unsung heroes of that area.
Delphi introduced a new object model while retaining the old object model for backward compatibility. The language was renamed to Delphi some time later to reflect this; while Object Pascal in practice meant the language that the Borland compilers compiled, its technical and historical meaning is both broader (more compilers) and more limited (a smaller language with different features).
Seems like they made quite a major pivot?
I remember them introducing Kylix and the disappointment of it being based on Qt and Wine so slow on my old Linux box. The VCL stagnated too (horrible flicker on XP as I recall, to begin with so hacks to disable theming via the application manifest were needed) and the compiler let you do illegal things in C++ in Codegear's C++ Builder 7 (must dig out an example). The installer for C++ Builder 7 took FOREVER to run and also required you keep all of your setup files in your temp directory for later updates to work (???? insane eh!)
I remember them releasing a paid PHP editor etc. at the time when you could just grab Netbeans and use that for £0.00 - difficult to compete with that!
The bit you're probably looking for is at http://www.embarcadero.com/ now. Some of the old people like David Intersimone are still there.
I worked with Delphi for a long time, through versions 3, 5 and 7 (the odd numbers were always better). When .NET came, the whole situation went crazy and never recovered. I can't remember the twists and turns now, but I think they released a .NET only RAD Studio which was awful, then they added the Win32 bits back but Delphi.NET was still awful. Then they dropped .NET and incorporated Remobjects Chrome/Oxygene as Delphi Prism, which was an Object Pascal inspired .NET language. Now they've split again, and Radstudio is all about Firemonkey, a cross-platform UI library. Remobjects are doing their own thing.
In my opinion, Delphi needs to just die, and the people/companies that have code bases built on it need to rewrite. There are lots of choices for software development these days, I don't think Delphi stands out for any particular use case in the modern world. But hey, maybe I'm just bitter after RAD Studio crashed on me one too many times...
Anyone wanting Pascal/Delphi today should use Lazaurus IDE w/ Free Pascal Compiler. Compatible with Delphi where it mattered, aiming for better in other areas, open-source, and cross-platform. Best use case is a C or C++ replacement that's safer, easy to read, and supports computers with little resources. Go's not there yet on runtime side.
Or, for that matter, Nim, which also has a huge amount of Pascal heritage.
Go is a hybrid of Oberon and C (with semantics leaning more towards Oberon and syntax more towards C, but they're both mixed in), and Nim is Modula-3 semantics married to Python syntax (with the best parts of a bunch of other languages thrown in). Both Oberon and Modula-3 are descended from Modula-2, which in turn is descended from Pascal.
Personally, I'm more in the Nim camp, partially because I prefer Modula-3 to Oberon, partially because I prefer Nim's Pythonesque syntax to Go's C/Oberon mashup syntax, and partially because Nim's metaprogramming features are truly beautiful.
I think you meant Pascal?
(...and edited)
I was a bit concerned about the maturity, compiler complexity, available libraries, and so on about Nim. I figured it might be in alpha quality or something given it's so new. So, I was hesitant to try it. I might give it a go sometime soon reading comments like yours.
Btw, do you have experience with its macro system? Any take-it-to-next-level language needs at least good macros and preferably great ones. Top contenders of my recent research are Racket, Julia, and Red. If Nim is more like Modula3/Python & has good macros, then it might be a credible contender due to mainstream programmers being able to pick it up more easily than really weird languages.
However, even Turbo Pascal was more expressive than Go in terms of language features (not taking the GC into account). Delphi even more so, specially if one takes into consideration the VCL and IDE.
But, it would be nice to see someone come up with a System 3 Gadgets library for Go, or an environment like BlackBox Component Builder.
It was fast, efficient, easy to use, with a great community, good tooling and the picky type system tended to find a lot of potential bugs at compile time (once you got used to it).
Now there are a lot of alternatives and to be honest, I can't really think of a reason you'd choose it any more - even if you /did/ want to create Windows native apps.
It's incredibly fast. You know how Go and C++ start with tiny applications ? The app starts up 0.2 seconds after you've finished typing the command. Delphi does that for 150000 lines applications. Your executables are decently sized (2-5 megabytes for large apps, kilobytes for small games and the like. Especially Go and C++ have problems with executable size. Go's hello world is still > 2 megabytes, and large go apps have huge binary sizes (dozens of megabytes), despite not containing spectacular amounts of code. Large C++ binaries, statically linked, are dozens to hundreds of megabytes (and God help you if you turn on debug info. I've known compiling a webserver + database app in C++ that actually failed to compile due to the single binary filling up the disk that had ~18 Gigabytes of free space (the binary, once compiled was 1.8 gigabytes, the rest was intermediate files)).
The number of add-ons, controls, database connectivity, install software, ... available for Delphi defies belief and they're extremely high quality.
It's extremely unlikely to change in backwards incompatible ways. Your code will keep working, and will keep looking and working the way it does now (compared to java or shudder the web, it's heaven)
Of course, there are downsides : manual memory allocation is a bit inconvenient (but very fast), HTTP/JSON communication is tricky. Nobody trusts .exe files anymore (for good reason, of course, but ...). It's unlikely to impress when judged on the last buzzwords.
Borland decided that the new shiny thing was "enterprise client/server middleware" — whatever that was. The new Inprise products were oriented towards building distributed client/server database apps using DCOM and the all-too-obviously-dead-on-arrival CORBA.
This was right around the time the web took off, but before the inane "enterprise Java application server" market exploded. Borland had a hard time competing with Java, and they started to neglect the stuff that had made Delphi such a powerful proposition in the first place.
Nooo... Another account of TP origins was that it was written by Philippe Kahn (the founder of Borland), back when he was just a one-man operation running from a small office on top of a Jaguar car service shop. But apparently it wasn't. Damn.
The documentation was very helpful, though, in getting to know Pascal. Taking over maintenance of an application written in a languange you can read but hardly write (whatever bad things people might be tempted to say about Pascal, cryptic syntax is not among them, I am certain) is a strange process.