6 ms·

21 Algol 60 Compilers in 1962

56 points by elvis70 2y ago

int_19h 2y ago
Algol 60 is also ... not exactly the easiest language to compile, even today. Here's the spec: https://www.masswerk.at/algol60/report.htm https://www.masswerk.at/algol60/report.htm Call by name in particular can be very tricky, especially where it intersects with higher-order functions. It can also be interesting to read contemporary discussions of problematic spots in the language, e.g.: https://dl.acm.org/doi/10.1145/366193.366209 https://dl.acm.org/doi/10.1145/366193.366209 https://dl.acm.org/doi/10.1145/363717.363743 https://dl.acm.org/doi/10.1145/363717.363743 And the original ALGOL bulletin which has committee reports and mailing lists for the design process: https://archive.computerhistory.org/resources/text/algol/algol_bulletin/ https://archive.computerhistory.org/resources/text/algol/alg...
- pjmlp 2y ago
  Yet it has relatively fast compilers, than a couple of modern languages, even on aging hardware versus the gaming rigs required for those modern languages.
  - fredrikholm 2y ago
    I wonder if there's some type of generational amnesia where the subjective definition of what constitutes fast gets slower and slower with time, where communicating ones frustration with slow software is met with comments about how software is not actually slow.
    - pjmlp 2y ago
      There is definitely one, see the amazement of Go compile times, versus what Turbo Pascal was doing on MS-DOS computers running at 20 MHz. Turbo Pascal is just an example from the days when C and C++ were yet to rule the Zeitgeist, and we had scripting all over the place.
      - anthk 2y ago
        Free Pascal is not a powerhouse building large FP+SDL projects such as GearHead 1 and 2. A comparable 486 program for DOS would be almost as slow if it was backported to DOS+FPC.
        pjmlp 2y ago
        Maybe, but that isn't Borland's Turbo Pascal compiler, nor Borland/Inprise/Embarcadero's Delphi. Most likely a consequence of how many compiler writers care about optimizations in FPC codebase.
      - no1lives4ever 2y ago
        Turbo Pascal back in the day was super fast. One of the fastest compiled languages I had used before we had incremental compilers and background incremental compilation. C/C++ compilers have mostly been a lot slower than those old Turbo Pascal implementations. MS Quick C 1.1 was a notable exception in the C compiler space. It could do 1 pass in memory compilation of most c code. Modern frameworks feel way slower even with scripting languages that require no compiles. Coming to think of it, my 486 from early 90s when running DOS was one of the fastest computers I have used when it comes to bootup and applicaion load times. I was like type name of program, press enter and the program is up and ready to use. The systems that I had before that did take a lot longer to launch programs and anything with Windows has always felt an order of a magnitude slower. Modern tiny linux disros can match that speed, but then that is only with a very slimmed down system minus any gui. The MacBook Pro with M1 Pro did feel a lot faster than previous macs or windows machines when it came to application launch times and general gui responsiveness, but still no match to those DOS systems.
        deterministic 2y ago
        My experience as well. Apparently the Turbo Pascal developer implemented the compiler as a one pass compiler generating machine code while parsing. It dramatically reduces memory usage and increase speed, while reducing the opportunity to optimize the machine code at a higher level.
      - 2y ago
    - pfdietz 2y ago
      This is accompanied by surprised reactions when maintained and polished old implementations come across as fast. I'm thinking of you, Common Lisp. I think there's also the effect that old, polished software can tend to become increasingly optimized.
  - int_19h 2y ago
    Modern languages generally have much fancier type systems (Algol 60 didn't even have records!). Perhaps more importantly, modern compilers do optimizations that I doubt anyone back in 1960s even dreamed of.
    - pjmlp 2y ago
      Yet the specific problem of compilation times only affect a subset of modern languages, e.g. it takes a fraction of time to compile an Ada/SPARK application versus C++, or Rust, although the type system is equally rather complex. Or the development workflow in Haskell and OCaml is much better than Rust, despite having a rather complex type system, because those ecosystems have invested into having interpreted toolchains, also able to load compiled code.
      - int_19h 2y ago
        The way Ada handles generics removes a lot of complexity wrt things like inference and overload resolution, but at the expense of making things less convenient for the programmer because of the need to explicitly instantiate. Rust and C++ are at this weird intersection of features where, on one hand, they need to have very fancy optimizers to remove all the overhead that idiomatic high-level library code (including stdlib) has, and on the other, they have generics and some degree of type inference that results in lots of generated code that consequently needs to go through the optimizer. You can argue that it is that intersection that it itself problematic. But then again, C++ is arguably so popular precisely because it offers it, and Rust became popular because it was the first thing other than C++ that targeted the same broad niche.
        pjmlp 2y ago
        Ada 2022/SPARK has plenty of complex language features, not sure why callout to generics in particular. Using C++23 modules (import std) is quite fast, even more so with binary libraries, or the proprietary C++ Builder packages, and has been proven that the reason Rust is slow is the amount of unoptimized IR code the frontend shoves down into LLVM backend, and not the type system. What I argue is the lack of investment in compiler tooling, once upon a time IBM and Lucid, showed the world how to have a Smalltalk/Lisp Machine like experience with C++ for example.
- Rochus 2y ago
  > not exactly the easiest language to compile Besides "call by name", also using gotos for dynamic non-local exits, even by passing labels as an argument to a procedure, is pretty tricky.
usr1106 2y ago
How many C or C++ compilers are in wider use today? Not really working in the area and did not research now, but I can come up with: * gcc * clang * Microsoft probably has their own implementation * Intel probably still has their own implementation * ? Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use Edit2: ARM of course
- shiomiru 2y ago
  tcc is popular too, as a fast non-optimizing compiler.
  - cenamus 2y ago
    Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.
    - mananaysiempre 2y ago
      The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.) [1] https://briancallahan.net/blog/20211010.html https://briancallahan.net/blog/20211010.html
      - cenamus 2y ago
        Those results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on
        mananaysiempre 2y ago
        Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.
glimshe 2y ago
One cool thing about Algol is that, while the language itself is over 60 years old, most modern programmers can have a decent understanding of source code written in it. It's a bit like reading 17th century English. You don't quite understand everything, but you can grasp most of it. I wonder why the retrocomputing crowd hasn't done much in ALGOL. Perhaps because it's just easier to write in BASIC, which was influenced by it.
- pjmlp 2y ago
  Probably because of the mix with nostalgia, and the folks that would be nostalgic about Algol 60 hardly care about computers nowadays. When I was a kid, the systems that we cared about were 8 bit home systems, starting with anything CP/M, and then there was the whole big machines being used at universities and our parents jobs, which we only knew from computer magazines.
- anthk 2y ago
  Spaniard here; Spanish is like Lisp. Reading 17th century Spanish is almost a no brainer minus some Medieval knights' jargon (put from Cervantes on purpose on making fun on old-farts) and some 17th jargon too, specially from popular sayings just said in La Mancha region which are still in use because they are related to daily farm/fields/food but the rest of Spain has no clear references off. Also the RAE institution for the Spanish Language does something similar to SRFI's + RSR?s for Scheme.
- flohofwoe 2y ago
  IIRC Algol was already dead and buried in the 80's, it certainly wasn't relevant or even available on most computer systems an 80's teenager had access to. The most popular high level language on 8-bit home computers was certainly BASIC, for compiled languages probably some dialect of PASCAL, and maybe FORTH for something entirely different. BASIC didn't have to be a bad choice either, Acorn/BBC BASIC even had proper inline assembly.
  - TheOtherHobbes 2y ago
    It was pretty much dead by the mid-70s. PASCAL, C, FORTRAN, and COBOL killed it on mainframes + minis and it was too complex for micros. (Thus - BASIC.) The twitching corpse lived on in the form of JOVIAL for DOD work (until ADA happened), and CORAL persisted in the UK because of bureaucratic momentum. Simula was another derivative that lasted for a while. But C and PASCAL were better, simpler, equally productive languages. As soon as they appeared ALGOL 60 didn't really need to exist any more. And ALGOL 68 was an ALGOL too far.
ggm 2y ago
Algol 68 ftw!
smurpy 2y ago
My friend Colin Broughton completed the first full implementation of the Algo68 spec. Apparently there was some concern that it was not going to be implementable! https://en.wikipedia.org/wiki/FLACC https://en.wikipedia.org/wiki/FLACC
- int_19h 2y ago
  Reading the ALGOL 68 spec[1] today, it feels like complexity is mainly about the unusual verbiage used (which, as I understand, was equally unusual at the time, being introduced specifically for it). The language itself is pretty mundane by modern standards. [1] http://www.math.bas.bg/bantchev/place/algol68/a68rr.html http://www.math.bas.bg/bantchev/place/algol68/a68rr.html
gpderetta 2y ago
How many of them could pass Knuth test [1]? [1] https://en.wikipedia.org/wiki/Man_or_boy_test https://en.wikipedia.org/wiki/Man_or_boy_test
wordglyph 2y ago
Key Innovations Introduced by ALGOL 60: Block Structure: It introduced the concept of structuring code into blocks, which paved the way for modular programming. Formal Syntax: ALGOL 60 used Backus-Naur Form (BNF) to formally define its syntax, setting a standard for future language specifications. Recursion: It supported recursive function calls, which was revolutionary at the time. Lexical Scoping: It allowed nested functions and controlled variable scope. Platform Independence: It aimed to be machine-independent, making it suitable for documenting algorithms.

56 points by elvis70 2y ago

Algol 60 is also ... not exactly the easiest language to compile, even today. Here's the spec: https://www.masswerk.at/algol60/report.htm https://www.masswerk.at/algol60/report.htm Call by name in particular can be very tricky, especially where it intersects with higher-order functions. It can also be interesting to read contemporary discussions of problematic spots in the language, e.g.: https://dl.acm.org/doi/10.1145/366193.366209 https://dl.acm.org/doi/10.1145/366193.366209 https://dl.acm.org/doi/10.1145/363717.363743 https://dl.acm.org/doi/10.1145/363717.363743 And the original ALGOL bulletin which has committee reports and mailing lists for the design process: https://archive.computerhistory.org/resources/text/algol/algol_bulletin/ https://archive.computerhistory.org/resources/text/algol/alg...

pjmlp 2y ago
Yet it has relatively fast compilers, than a couple of modern languages, even on aging hardware versus the gaming rigs required for those modern languages.
- fredrikholm 2y ago
  I wonder if there's some type of generational amnesia where the subjective definition of what constitutes fast gets slower and slower with time, where communicating ones frustration with slow software is met with comments about how software is not actually slow.
  - pjmlp 2y ago
    There is definitely one, see the amazement of Go compile times, versus what Turbo Pascal was doing on MS-DOS computers running at 20 MHz. Turbo Pascal is just an example from the days when C and C++ were yet to rule the Zeitgeist, and we had scripting all over the place.
    - anthk 2y ago
      Free Pascal is not a powerhouse building large FP+SDL projects such as GearHead 1 and 2. A comparable 486 program for DOS would be almost as slow if it was backported to DOS+FPC.
      - pjmlp 2y ago
        Maybe, but that isn't Borland's Turbo Pascal compiler, nor Borland/Inprise/Embarcadero's Delphi. Most likely a consequence of how many compiler writers care about optimizations in FPC codebase.
    - no1lives4ever 2y ago
      Turbo Pascal back in the day was super fast. One of the fastest compiled languages I had used before we had incremental compilers and background incremental compilation. C/C++ compilers have mostly been a lot slower than those old Turbo Pascal implementations. MS Quick C 1.1 was a notable exception in the C compiler space. It could do 1 pass in memory compilation of most c code. Modern frameworks feel way slower even with scripting languages that require no compiles. Coming to think of it, my 486 from early 90s when running DOS was one of the fastest computers I have used when it comes to bootup and applicaion load times. I was like type name of program, press enter and the program is up and ready to use. The systems that I had before that did take a lot longer to launch programs and anything with Windows has always felt an order of a magnitude slower. Modern tiny linux disros can match that speed, but then that is only with a very slimmed down system minus any gui. The MacBook Pro with M1 Pro did feel a lot faster than previous macs or windows machines when it came to application launch times and general gui responsiveness, but still no match to those DOS systems.
      - deterministic 2y ago
        My experience as well. Apparently the Turbo Pascal developer implemented the compiler as a one pass compiler generating machine code while parsing. It dramatically reduces memory usage and increase speed, while reducing the opportunity to optimize the machine code at a higher level.
    - 2y ago
  - pfdietz 2y ago
    This is accompanied by surprised reactions when maintained and polished old implementations come across as fast. I'm thinking of you, Common Lisp. I think there's also the effect that old, polished software can tend to become increasingly optimized.
- int_19h 2y ago
  Modern languages generally have much fancier type systems (Algol 60 didn't even have records!). Perhaps more importantly, modern compilers do optimizations that I doubt anyone back in 1960s even dreamed of.
  - pjmlp 2y ago
    Yet the specific problem of compilation times only affect a subset of modern languages, e.g. it takes a fraction of time to compile an Ada/SPARK application versus C++, or Rust, although the type system is equally rather complex. Or the development workflow in Haskell and OCaml is much better than Rust, despite having a rather complex type system, because those ecosystems have invested into having interpreted toolchains, also able to load compiled code.
    - int_19h 2y ago
      The way Ada handles generics removes a lot of complexity wrt things like inference and overload resolution, but at the expense of making things less convenient for the programmer because of the need to explicitly instantiate. Rust and C++ are at this weird intersection of features where, on one hand, they need to have very fancy optimizers to remove all the overhead that idiomatic high-level library code (including stdlib) has, and on the other, they have generics and some degree of type inference that results in lots of generated code that consequently needs to go through the optimizer. You can argue that it is that intersection that it itself problematic. But then again, C++ is arguably so popular precisely because it offers it, and Rust became popular because it was the first thing other than C++ that targeted the same broad niche.
      - pjmlp 2y ago
        Ada 2022/SPARK has plenty of complex language features, not sure why callout to generics in particular. Using C++23 modules (import std) is quite fast, even more so with binary libraries, or the proprietary C++ Builder packages, and has been proven that the reason Rust is slow is the amount of unoptimized IR code the frontend shoves down into LLVM backend, and not the type system. What I argue is the lack of investment in compiler tooling, once upon a time IBM and Lucid, showed the world how to have a Smalltalk/Lisp Machine like experience with C++ for example.
Rochus 2y ago
> not exactly the easiest language to compile Besides "call by name", also using gotos for dynamic non-local exits, even by passing labels as an argument to a procedure, is pretty tricky.

usr1106 2y ago

How many C or C++ compilers are in wider use today? Not really working in the area and did not research now, but I can come up with: * gcc * clang * Microsoft probably has their own implementation * Intel probably still has their own implementation * ? Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use Edit2: ARM of course

shiomiru 2y ago
tcc is popular too, as a fast non-optimizing compiler.
- cenamus 2y ago
  Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.
  - mananaysiempre 2y ago
    The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.) [1] https://briancallahan.net/blog/20211010.html https://briancallahan.net/blog/20211010.html
    - cenamus 2y ago
      Those results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on
      - mananaysiempre 2y ago
        Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.

glimshe 2y ago

One cool thing about Algol is that, while the language itself is over 60 years old, most modern programmers can have a decent understanding of source code written in it. It's a bit like reading 17th century English. You don't quite understand everything, but you can grasp most of it. I wonder why the retrocomputing crowd hasn't done much in ALGOL. Perhaps because it's just easier to write in BASIC, which was influenced by it.

pjmlp 2y ago
Probably because of the mix with nostalgia, and the folks that would be nostalgic about Algol 60 hardly care about computers nowadays. When I was a kid, the systems that we cared about were 8 bit home systems, starting with anything CP/M, and then there was the whole big machines being used at universities and our parents jobs, which we only knew from computer magazines.
anthk 2y ago
Spaniard here; Spanish is like Lisp. Reading 17th century Spanish is almost a no brainer minus some Medieval knights' jargon (put from Cervantes on purpose on making fun on old-farts) and some 17th jargon too, specially from popular sayings just said in La Mancha region which are still in use because they are related to daily farm/fields/food but the rest of Spain has no clear references off. Also the RAE institution for the Spanish Language does something similar to SRFI's + RSR?s for Scheme.
flohofwoe 2y ago
IIRC Algol was already dead and buried in the 80's, it certainly wasn't relevant or even available on most computer systems an 80's teenager had access to. The most popular high level language on 8-bit home computers was certainly BASIC, for compiled languages probably some dialect of PASCAL, and maybe FORTH for something entirely different. BASIC didn't have to be a bad choice either, Acorn/BBC BASIC even had proper inline assembly.
- TheOtherHobbes 2y ago
  It was pretty much dead by the mid-70s. PASCAL, C, FORTRAN, and COBOL killed it on mainframes + minis and it was too complex for micros. (Thus - BASIC.) The twitching corpse lived on in the form of JOVIAL for DOD work (until ADA happened), and CORAL persisted in the UK because of bureaucratic momentum. Simula was another derivative that lasted for a while. But C and PASCAL were better, simpler, equally productive languages. As soon as they appeared ALGOL 60 didn't really need to exist any more. And ALGOL 68 was an ALGOL too far.

ggm 2y ago

Algol 68 ftw!

smurpy 2y ago

My friend Colin Broughton completed the first full implementation of the Algo68 spec. Apparently there was some concern that it was not going to be implementable! https://en.wikipedia.org/wiki/FLACC https://en.wikipedia.org/wiki/FLACC

int_19h 2y ago
Reading the ALGOL 68 spec[1] today, it feels like complexity is mainly about the unusual verbiage used (which, as I understand, was equally unusual at the time, being introduced specifically for it). The language itself is pretty mundane by modern standards. [1] http://www.math.bas.bg/bantchev/place/algol68/a68rr.html http://www.math.bas.bg/bantchev/place/algol68/a68rr.html

gpderetta 2y ago

How many of them could pass Knuth test [1]? [1] https://en.wikipedia.org/wiki/Man_or_boy_test https://en.wikipedia.org/wiki/Man_or_boy_test

wordglyph 2y ago

Key Innovations Introduced by ALGOL 60: Block Structure: It introduced the concept of structuring code into blocks, which paved the way for modular programming. Formal Syntax: ALGOL 60 used Backus-Naur Form (BNF) to formally define its syntax, setting a standard for future language specifications. Recursion: It supported recursive function calls, which was revolutionary at the time. Lexical Scoping: It allowed nested functions and controlled variable scope. Platform Independence: It aimed to be machine-independent, making it suitable for documenting algorithms.