4 ms·

OP contains a lengthy section titled "Why have a machine language?" Toward the end of Knuth's answer is: "Therefore I will continue to use English as the high

OP contains a lengthy section titled "Why have a machine language?" Toward the end of Knuth's answer is: "Therefore I will continue to use English as the high-level language in TAOCP, and I will continue to use a low-level language to indicate how machines actually compute. Readers who only want to see algorithms that are already packaged in a plug-in way, using a trendy language, should buy other people's books.

wyager 9y ago
This is dumb. There's no expressive benefit to implementing algorithms as assembly, especially imaginary assembly. "How machines actually compute" at the assembly level isn't even of interest until you need to make your algorithm go faster, at which point you need to target a real platform, not an imaginary one.
- b0rsuk 9y ago
  Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur. I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren't the point of my books, the point is rather what you can do in your favorite language. -- from the article
  - wyager 9y ago
    Ok, cool, so use a pseudocode syntax easily understood by anyone familiar with basic control flow constructs. Most algorithms books do this, and even if they're ugly, they're certainly better than a made up assembly language.
    - defanor 9y ago
      That pseudocode is "English as the high-level language", as I understand it. Basic and common notation is used there, it's not plain English. Edit: though it's indeed not used extensively to denote control flow: that is done with "go to".
      - deleted 9y ago
        [deleted]
    - b0rsuk 9y ago
      Most schools around the world teach you maths, even though vast majority of people doesn't use maths at work - not directly. So why bother ? Surely primary school math would be enough for everyone except specialists ? While I'm skeptical of value of maths for programming, I can't deny that the process of learning and practicing maths teaches you valuable skills: discipline, thinking outside the box, logic, looking at things from different points of view, concentration, persistence, attention to detail... Now Assembly programming requires many of the same skills, AND it's close to metal. It's how computers actually work. At the end of the day, all programming languages are written in asm or can be written in asm. You can't escape physics and relationships between parts of processor. It doesn't matter if a programming language is imperative or functional, or OO, the rules are the same for all. There are high level language constructs which can represent complex things in simple ways, but if you don't know how processors and algorithms work, you're playing a lottery, not optimizing a program. Having low level knowledge pays off even if using a high level language. It's good to know what's physically possible. ---------- Side note, inspired by this post... how do I post a "ASK HN" post ? I'm not 100% sure if I do this right, the last time I left the "URL" field empty but my submission looked like a normal submission, no "ASK HN" in title etc.
      - kwhitefoot 9y ago
        > While I'm skeptical of value of XXXX for YYYY, I can't deny that the process of learning and practicing XXXX teaches you valuable skills: discipline, thinking outside the box, logic, looking at things from different points of view, concentration, persistence, attention to detail... This has been used as a justification for teaching all sorts of things down the ages (Latin, geometry, martial arts, soldiering, etc.). Why not teach the "valuable skills" instead?
- pg314 9y ago
  > There's no expressive benefit to implementing algorithms as assembly You can't write coroutines in portable C. You can in assembly. You can't write an efficient interpreter dispatch table in portable C (you need extensions like 'computed goto'). You can in assembly.
  - vanjoe 9y ago
    Is this true? I don't know anything about writing interpreters, but wouldn't function pointers work?
    - haldean 9y ago
      You can kind of do it with function pointers, with the caveat that a jump table of function pointers is still going to have the cost of a function call. What you can't do is something equivalent to: sta $1 jmp ($1) which just moves the PC forward by the offset stored in a register (I only know 6502 assembly, sorry everyone). There's no function call here, it's a goto where you calculate what label to go to at runtime. The closest C equivalent would be a switch/case; switch/case has the relative disadvantage that you have to make an explicit label to be targeted for each one, and it becomes difficult to express anything other than "the thing I'm jumping to is parameterized by only this one integer".
    - KMag 9y ago
      One call/return pair, plus the increased chance of a cache miss, makes the overhead of a function dispatch for each and every opcode rather high, unless your opcodes are very complex and do a lot of work before returning to your opcode dispatch loop. The normal computed goto dispatch puts a goto opcode_table[*(++ip)]; at the end of each case statement. This essentially inlines a copy of the switch(*(++ip)) into each opcode case. This saves one branch instruction, but more importantly, it really helps the branch predictor by giving each opcode its own copy of the code for dispatching the next opcode. So, if 90% of the time your compare opcode is followed by a jump_less_than opcode, the CPU will prefetch and start speculatively executing the conditional jump before the interpreter is done with the compare opcode. In C, if you don't use non-portable computed goto, generally the best you can do for opcode dispatch is using a big switch statement. In theory, C compiler writers could write some pretty accurate heuristics (loop containing only a switch statement switching on an indirection indexed by a constant incriment) and detect interpreter bytecode dispatch inner loops. It wouldn't be too difficult to implement an optimization that results in the same instruction sequence as the computed goto dispatch. However, it would be too brittle for any interpreter writer to rely on the compiler performing the optimization, so most would continue to use computed goto.
- brett40324 9y ago
  I'd argue that how machines actually compute at the assembly level is very much of interest to numerous people of many backgrounds and professions.
- torrent-of-ions 9y ago
  The expressive benefit is that you can do anything you can do with a real computer. Using a high level language forces you to see the world through that lens. But the book is not concerned with how you implement algorithms in C, it is concerned with how you implement algorithms on a computer.
- guscost 9y ago
  > until you need to make your algorithm go faster, at which point you need to target a real platform, not an imaginary one. ...also at which point you will be thinking "maybe I could have learned how to do this in a controlled environment first?"
- Jtsummers 9y ago
  I learned assembly with a Motorola 68k emulator. While the particular instruction set is different from the hardware I use today, is that experience useless from an educational point of view? Would it be better to have not learned it at all? It's not a fantasy system, but it's not commonly used anymore so it's as good as fantasy.

wyager 9y ago

This is dumb. There's no expressive benefit to implementing algorithms as assembly, especially imaginary assembly. "How machines actually compute" at the assembly level isn't even of interest until you need to make your algorithm go faster, at which point you need to target a real platform, not an imaginary one.

b0rsuk 9y ago
Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur. I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren't the point of my books, the point is rather what you can do in your favorite language. -- from the article
- wyager 9y ago
  Ok, cool, so use a pseudocode syntax easily understood by anyone familiar with basic control flow constructs. Most algorithms books do this, and even if they're ugly, they're certainly better than a made up assembly language.
  - defanor 9y ago
    That pseudocode is "English as the high-level language", as I understand it. Basic and common notation is used there, it's not plain English. Edit: though it's indeed not used extensively to denote control flow: that is done with "go to".
    - deleted 9y ago
      [deleted]
  - b0rsuk 9y ago
    Most schools around the world teach you maths, even though vast majority of people doesn't use maths at work - not directly. So why bother ? Surely primary school math would be enough for everyone except specialists ? While I'm skeptical of value of maths for programming, I can't deny that the process of learning and practicing maths teaches you valuable skills: discipline, thinking outside the box, logic, looking at things from different points of view, concentration, persistence, attention to detail... Now Assembly programming requires many of the same skills, AND it's close to metal. It's how computers actually work. At the end of the day, all programming languages are written in asm or can be written in asm. You can't escape physics and relationships between parts of processor. It doesn't matter if a programming language is imperative or functional, or OO, the rules are the same for all. There are high level language constructs which can represent complex things in simple ways, but if you don't know how processors and algorithms work, you're playing a lottery, not optimizing a program. Having low level knowledge pays off even if using a high level language. It's good to know what's physically possible. ---------- Side note, inspired by this post... how do I post a "ASK HN" post ? I'm not 100% sure if I do this right, the last time I left the "URL" field empty but my submission looked like a normal submission, no "ASK HN" in title etc.
    - kwhitefoot 9y ago
      > While I'm skeptical of value of XXXX for YYYY, I can't deny that the process of learning and practicing XXXX teaches you valuable skills: discipline, thinking outside the box, logic, looking at things from different points of view, concentration, persistence, attention to detail... This has been used as a justification for teaching all sorts of things down the ages (Latin, geometry, martial arts, soldiering, etc.). Why not teach the "valuable skills" instead?
pg314 9y ago
> There's no expressive benefit to implementing algorithms as assembly You can't write coroutines in portable C. You can in assembly. You can't write an efficient interpreter dispatch table in portable C (you need extensions like 'computed goto'). You can in assembly.
- vanjoe 9y ago
  Is this true? I don't know anything about writing interpreters, but wouldn't function pointers work?
  - haldean 9y ago
    You can kind of do it with function pointers, with the caveat that a jump table of function pointers is still going to have the cost of a function call. What you can't do is something equivalent to: sta $1 jmp ($1) which just moves the PC forward by the offset stored in a register (I only know 6502 assembly, sorry everyone). There's no function call here, it's a goto where you calculate what label to go to at runtime. The closest C equivalent would be a switch/case; switch/case has the relative disadvantage that you have to make an explicit label to be targeted for each one, and it becomes difficult to express anything other than "the thing I'm jumping to is parameterized by only this one integer".
  - KMag 9y ago
    One call/return pair, plus the increased chance of a cache miss, makes the overhead of a function dispatch for each and every opcode rather high, unless your opcodes are very complex and do a lot of work before returning to your opcode dispatch loop. The normal computed goto dispatch puts a goto opcode_table[*(++ip)]; at the end of each case statement. This essentially inlines a copy of the switch(*(++ip)) into each opcode case. This saves one branch instruction, but more importantly, it really helps the branch predictor by giving each opcode its own copy of the code for dispatching the next opcode. So, if 90% of the time your compare opcode is followed by a jump_less_than opcode, the CPU will prefetch and start speculatively executing the conditional jump before the interpreter is done with the compare opcode. In C, if you don't use non-portable computed goto, generally the best you can do for opcode dispatch is using a big switch statement. In theory, C compiler writers could write some pretty accurate heuristics (loop containing only a switch statement switching on an indirection indexed by a constant incriment) and detect interpreter bytecode dispatch inner loops. It wouldn't be too difficult to implement an optimization that results in the same instruction sequence as the computed goto dispatch. However, it would be too brittle for any interpreter writer to rely on the compiler performing the optimization, so most would continue to use computed goto.
brett40324 9y ago
I'd argue that how machines actually compute at the assembly level is very much of interest to numerous people of many backgrounds and professions.
torrent-of-ions 9y ago
The expressive benefit is that you can do anything you can do with a real computer. Using a high level language forces you to see the world through that lens. But the book is not concerned with how you implement algorithms in C, it is concerned with how you implement algorithms on a computer.
guscost 9y ago
> until you need to make your algorithm go faster, at which point you need to target a real platform, not an imaginary one. ...also at which point you will be thinking "maybe I could have learned how to do this in a controlled environment first?"
Jtsummers 9y ago
I learned assembly with a Motorola 68k emulator. While the particular instruction set is different from the hardware I use today, is that experience useless from an educational point of view? Would it be better to have not learned it at all? It's not a fantasy system, but it's not commonly used anymore so it's as good as fantasy.