5 ms·

The examples compile super fast. How long did it use to take?

lkesteloot 13y ago
I remember compilation being nearly instantaneous.
kristiandupont 13y ago
..Turbo Pascal was sort of shocking, since it basically did everything that IBM Pascal did, only it ran in about 33K of memory including the text editor. This was nothing short of astonishing. Even more astonishing was the fact that you could compile a small program in less than one second. It's as if a company you had never heard of introduced a clone of the Buick LeSabre which could go 1,000,000 MPH and drive around the world on so little gasoline than an ant could drink it without getting sick. http://www.joelonsoftware.com/articles/fog0000000023.html http://www.joelonsoftware.com/articles/fog0000000023.html I miss Joel's writing!
- corysama 13y ago
  This article from 2009 came up again recently explaining how Turbo Pascal was so fast back on an 8MHz 8088 http://prog21.dadgum.com/47.html http://prog21.dadgum.com/47.html
- vidarh 13y ago
  It was only shocking to people used to complicated behemoths of multi-pass compilers or complicated optimizing compilers with expensive internal representations. Turbo Pascal really mostly "only" does things the way Wirth used to: As simple as possible. Wirth's languages are all designed for single pass compilation with direct code generation, and if you write your compilers that way, they will be fast. It is very, very hard not to make them fast that way. His compiler textsbooks, all the way back to "Compilerbay" in 1977 (using PL/0 as the language) included full source code for compilers following that style, and they're so small the entire compilers fit in a few handful pages. (EDIT: just to make clear: I do admire Turbo Pascal - I used it quite a lot, but main the genius of Turbo Pascal was to pick the Wirth way of doing compilers and integrate it with a simple "IDE" - a large part of the amazing impression of Turbo Pascal was that you did not have to write your code to disk, exit the editor, run a compiler etc. but could do it all in one)
  - acqq 13y ago
    I remember that differently: on Z80 CPU machines, UCSD Pascal was slow. It compiled to the p-code (it was both an "operating system and compiler" and they wanted it portable). On the first PC's (8088 CPU), Microsoft's Pascal was slow. It produced obj files. Turbo Pascal was lightning fast on both. It had to be implemented contrary to beliefs common then: it was itself written in asm, it was never just a compiler but the editor and compiler at once, kept everything in memory if it could, produced the pure native code processor specific and never produced obj files.
    - cek 13y ago
      You remember correctly (at least your memories jive with mine). UCSD Pascal was, at best, 'functional'.
    - vidarh 13y ago
      UCSD Pascal was slow because the compiler was written in Pascal and compiled to p-code itself (the source is available: http://techtransfer.universityofcalifornia.edu/NCD/19327.html http://techtransfer.universityofcalifornia.edu/NCD/19327.htm... ). It was not a good benchmark. It was prevalent because it was trivial to port, not because it was good. (Note that UCSD Pascal was based on a part of Wirths research groups "porting kit" - their intent was not for p-code to be used for production systems, but as an easy way of getting a Pascal compiler running on a new platform to be able to then use the target platform while retargeting the code generator) > It had to be implemented contrary to beliefs common then: it was itself written in asm, That was nothing out of the ordinary at the time, though not something Wirth himself did, as a large part of his mission was to teach the development of compilers. But compilers for small systems were often written in asm at the time. It'd not be very viable to write compilers in high level languages for a C64 or other home computers, for example, yet there were plenty of compilers for small systems. When I wrote my first compilers on the C64 and a bit later on the Amiga, it never even occurred to me to write them in a high level language until a few years later (incidentally when I got HiSoft Pascal - an integrated Pascal environment for the Amiga very much in the spirit of Turbo Pascal) > it was never just a compiler but the editor and compiler at once, kept everything in memory if it could, produced the pure native code processor specific and never produced obj files. That's technically true, though the compiler that became Turbo Pascal was actually originally a separate, stand alone compiler. Combining the compiler with the editor was fairly uncommon and certainly innovative. When Kahn at Borland decided he wanted an environment like that, though, he went out and bought an existing, standalone, commercial compiler, from Anders Hejlsberg, and brought him to Borland. Producing pure native code on the other hand was not unusual - UCSD's p-System was an aberration in that respect, and it's greatest lasting legacy was in inspiring VM based systems; e.g. Bill Joy has cited it as one of the inspirations behind the JVM. Not producing object files was also quite common - for many small systems there was no tradition of object files at all, as they were too small for separate compilation to make much sense.
- cpeterso 13y ago
  When I need some inspiration, I just reread "Things That Turbo Pascal is Smaller Than": http://prog21.dadgum.com/116.html http://prog21.dadgum.com/116.html
vidarh 13y ago
Not much time... Pascal (and most of Niklaus Wirth's languages) was designed to be easy to compile. The grammars are very small (typically less than a page of text; Turbo Pascal used to include the full BNF grammer in the manual), and his languages are designed to be possible to compile in one pass. Also "traditional" Wirth-style compilers usually output code directly rather than build an abstract syntax tree and a lot of compilers of the era were heavily influenced by his compiler textbook, which included the full source of a compiler.. They also tend to output object files or final executables directly rather than go via an assembler. All of that combine to make it very easy to make the compilers very small, and very fast even on very slow machines. For an example of simplicty, take a look at the source code to an educational Oberon-0 (subset of his Oberon language) compiler, from one of his books: http://www.inf.ethz.ch/personal/wirth/books/CompilerConstruction/ http://www.inf.ethz.ch/personal/wirth/books/CompilerConstruc... (it generates code for a virtual RISC machine, and one of the files includes an interpreter for the generated code) The whole book is available as a PDF here: http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf ; Wirth's material on compiler contruction evolved over the years from an early book about writing a PL/0 compiler, through Pascal and Modula (2) and finally Oberon, but always focusing on simplicity. For a time I wanted to go to ETH Zurich to study computer science there because of Wirth. I'm a bit of a Wirth fanboy (which is ironic, since my favourite language these days is Ruby - a language that is pretty much the anti-thesis of Wirth's focus on simplicity of implementation). As as a final digression, lets play six (well, 3) degrees of Pascal to Javascript: One of Wirth's PhD students was Michael Franz who got his PhD with a one of my favourite dissertations, on dynamic architecture independent code generation for Oberon. Dr Michael Franz co-invented the trace-trees technique that went into Mozilla's TraceMonkey version of their javascript JIT with Andreas Gal. Andreas Gal now works at Mozilla with Brendan Eich, the creator of Javascript.
- lkesteloot 13y ago
  Exactly right. Turbo Pascal compiled straight to machine language, which made it hard for them to do nice optimizations. But people like me didn't care. IBM's compiler couldn't blow off optimizations, though. Typical worse-is-better. This compiler started out as a five-pass compiler, then I reduced it to two. I could have reduced it to one and simplified the code quite a bit, but having the intermediate parse tree made debugging easier. The parse and compile passes together take less than 20ms on the largest Pascal program I have (rose.pas).

I remember compilation being nearly instantaneous.

..Turbo Pascal was sort of shocking, since it basically did everything that IBM Pascal did, only it ran in about 33K of memory including the text editor. This was nothing short of astonishing. Even more astonishing was the fact that you could compile a small program in less than one second. It's as if a company you had never heard of introduced a clone of the Buick LeSabre which could go 1,000,000 MPH and drive around the world on so little gasoline than an ant could drink it without getting sick. http://www.joelonsoftware.com/articles/fog0000000023.html http://www.joelonsoftware.com/articles/fog0000000023.html I miss Joel's writing!

corysama 13y ago
This article from 2009 came up again recently explaining how Turbo Pascal was so fast back on an 8MHz 8088 http://prog21.dadgum.com/47.html http://prog21.dadgum.com/47.html
vidarh 13y ago
It was only shocking to people used to complicated behemoths of multi-pass compilers or complicated optimizing compilers with expensive internal representations. Turbo Pascal really mostly "only" does things the way Wirth used to: As simple as possible. Wirth's languages are all designed for single pass compilation with direct code generation, and if you write your compilers that way, they will be fast. It is very, very hard not to make them fast that way. His compiler textsbooks, all the way back to "Compilerbay" in 1977 (using PL/0 as the language) included full source code for compilers following that style, and they're so small the entire compilers fit in a few handful pages. (EDIT: just to make clear: I do admire Turbo Pascal - I used it quite a lot, but main the genius of Turbo Pascal was to pick the Wirth way of doing compilers and integrate it with a simple "IDE" - a large part of the amazing impression of Turbo Pascal was that you did not have to write your code to disk, exit the editor, run a compiler etc. but could do it all in one)
- acqq 13y ago
  I remember that differently: on Z80 CPU machines, UCSD Pascal was slow. It compiled to the p-code (it was both an "operating system and compiler" and they wanted it portable). On the first PC's (8088 CPU), Microsoft's Pascal was slow. It produced obj files. Turbo Pascal was lightning fast on both. It had to be implemented contrary to beliefs common then: it was itself written in asm, it was never just a compiler but the editor and compiler at once, kept everything in memory if it could, produced the pure native code processor specific and never produced obj files.
  - cek 13y ago
    You remember correctly (at least your memories jive with mine). UCSD Pascal was, at best, 'functional'.
  - vidarh 13y ago
    UCSD Pascal was slow because the compiler was written in Pascal and compiled to p-code itself (the source is available: http://techtransfer.universityofcalifornia.edu/NCD/19327.html http://techtransfer.universityofcalifornia.edu/NCD/19327.htm... ). It was not a good benchmark. It was prevalent because it was trivial to port, not because it was good. (Note that UCSD Pascal was based on a part of Wirths research groups "porting kit" - their intent was not for p-code to be used for production systems, but as an easy way of getting a Pascal compiler running on a new platform to be able to then use the target platform while retargeting the code generator) > It had to be implemented contrary to beliefs common then: it was itself written in asm, That was nothing out of the ordinary at the time, though not something Wirth himself did, as a large part of his mission was to teach the development of compilers. But compilers for small systems were often written in asm at the time. It'd not be very viable to write compilers in high level languages for a C64 or other home computers, for example, yet there were plenty of compilers for small systems. When I wrote my first compilers on the C64 and a bit later on the Amiga, it never even occurred to me to write them in a high level language until a few years later (incidentally when I got HiSoft Pascal - an integrated Pascal environment for the Amiga very much in the spirit of Turbo Pascal) > it was never just a compiler but the editor and compiler at once, kept everything in memory if it could, produced the pure native code processor specific and never produced obj files. That's technically true, though the compiler that became Turbo Pascal was actually originally a separate, stand alone compiler. Combining the compiler with the editor was fairly uncommon and certainly innovative. When Kahn at Borland decided he wanted an environment like that, though, he went out and bought an existing, standalone, commercial compiler, from Anders Hejlsberg, and brought him to Borland. Producing pure native code on the other hand was not unusual - UCSD's p-System was an aberration in that respect, and it's greatest lasting legacy was in inspiring VM based systems; e.g. Bill Joy has cited it as one of the inspirations behind the JVM. Not producing object files was also quite common - for many small systems there was no tradition of object files at all, as they were too small for separate compilation to make much sense.
cpeterso 13y ago
When I need some inspiration, I just reread "Things That Turbo Pascal is Smaller Than": http://prog21.dadgum.com/116.html http://prog21.dadgum.com/116.html

vidarh 13y ago

Not much time... Pascal (and most of Niklaus Wirth's languages) was designed to be easy to compile. The grammars are very small (typically less than a page of text; Turbo Pascal used to include the full BNF grammer in the manual), and his languages are designed to be possible to compile in one pass. Also "traditional" Wirth-style compilers usually output code directly rather than build an abstract syntax tree and a lot of compilers of the era were heavily influenced by his compiler textbook, which included the full source of a compiler.. They also tend to output object files or final executables directly rather than go via an assembler. All of that combine to make it very easy to make the compilers very small, and very fast even on very slow machines. For an example of simplicty, take a look at the source code to an educational Oberon-0 (subset of his Oberon language) compiler, from one of his books: http://www.inf.ethz.ch/personal/wirth/books/CompilerConstruction/ http://www.inf.ethz.ch/personal/wirth/books/CompilerConstruc... (it generates code for a virtual RISC machine, and one of the files includes an interpreter for the generated code) The whole book is available as a PDF here: http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf ; Wirth's material on compiler contruction evolved over the years from an early book about writing a PL/0 compiler, through Pascal and Modula (2) and finally Oberon, but always focusing on simplicity. For a time I wanted to go to ETH Zurich to study computer science there because of Wirth. I'm a bit of a Wirth fanboy (which is ironic, since my favourite language these days is Ruby - a language that is pretty much the anti-thesis of Wirth's focus on simplicity of implementation). As as a final digression, lets play six (well, 3) degrees of Pascal to Javascript: One of Wirth's PhD students was Michael Franz who got his PhD with a one of my favourite dissertations, on dynamic architecture independent code generation for Oberon. Dr Michael Franz co-invented the trace-trees technique that went into Mozilla's TraceMonkey version of their javascript JIT with Andreas Gal. Andreas Gal now works at Mozilla with Brendan Eich, the creator of Javascript.

lkesteloot 13y ago
Exactly right. Turbo Pascal compiled straight to machine language, which made it hard for them to do nice optimizations. But people like me didn't care. IBM's compiler couldn't blow off optimizations, though. Typical worse-is-better. This compiler started out as a five-pass compiler, then I reduced it to two. I could have reduced it to one and simplified the code quite a bit, but having the intermediate parse tree made debugging easier. The parse and compile passes together take less than 20ms on the largest Pascal program I have (rose.pas).