4 ms·

I believe that many compilers have an intermediate step that looks like a stack based language.

by foota 9y ago

jcranmer 9y ago
Compiler IRs are often based on reflecting expression DAGs rather than manipulating a finite register set or an infinite stack.
- exikyut 9y ago
  Manipulating an infinite stack sounds like a really big world of pain. I realize you're only ever poking around near the top, but if the system has the chance to grow infinitely, well, it will.
wolfgke 9y ago
> I believe that many compilers have an intermediate step that looks like a stack based language. I admit that in the 80th many compilers used something reminiscent of a stack based language for the code generation phase. The reason is that it is rather easy to write a code generator for an accumulator machine (do it as an exercise if you want). But this is not how typical modern compilers look like. Just to give one point of evidence beforehand: Modern processors have many more general purpose registers (x86-64 has 16 and AArch64 has 32, though some have reserved purposes). So such code would be a waste of the possibilities. A typical modern compiler looks like this (I am aware that your preferred compiler might have additional or somewhat different stages, but the following is typical): Frontend (very language-dependendent): - Tokenize input - Parse input (or report syntactical errors) to generate parse tree - Generate Abstract Syntax Tree (AST) - Do semantic analysis/type checking - Transform program in Static single assignment form (SSA form) Middleend (not much depdendent on language or machine) - Do optimizations on SSA code (e.g. liveness of variables/dead code elimination, constant propagation, peephole optimizations, perhaps replace whole algorithms) Backend (very machine-dependendent) - Do machine-dependent optimizations - Do register allocation - Generate machine-dependent code As one can see: A stack-based intermediate step does not appear hear (and is to my knowledge uncommon) - instead transformations on code in SSA form are common.

I believe that many compilers have an intermediate step that looks like a stack based language.

by foota 9y ago

I believe that many compilers have an intermediate step that looks like a stack based language.

Compiler IRs are often based on reflecting expression DAGs rather than manipulating a finite register set or an infinite stack.

exikyut 9y ago
Manipulating an infinite stack sounds like a really big world of pain. I realize you're only ever poking around near the top, but if the system has the chance to grow infinitely, well, it will.

wolfgke 9y ago

> I believe that many compilers have an intermediate step that looks like a stack based language. I admit that in the 80th many compilers used something reminiscent of a stack based language for the code generation phase. The reason is that it is rather easy to write a code generator for an accumulator machine (do it as an exercise if you want). But this is not how typical modern compilers look like. Just to give one point of evidence beforehand: Modern processors have many more general purpose registers (x86-64 has 16 and AArch64 has 32, though some have reserved purposes). So such code would be a waste of the possibilities. A typical modern compiler looks like this (I am aware that your preferred compiler might have additional or somewhat different stages, but the following is typical): Frontend (very language-dependendent): - Tokenize input - Parse input (or report syntactical errors) to generate parse tree - Generate Abstract Syntax Tree (AST) - Do semantic analysis/type checking - Transform program in Static single assignment form (SSA form) Middleend (not much depdendent on language or machine) - Do optimizations on SSA code (e.g. liveness of variables/dead code elimination, constant propagation, peephole optimizations, perhaps replace whole algorithms) Backend (very machine-dependendent) - Do machine-dependent optimizations - Do register allocation - Generate machine-dependent code As one can see: A stack-based intermediate step does not appear hear (and is to my knowledge uncommon) - instead transformations on code in SSA form are common.