Timeline for Is source code generation an anti-pattern?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 17, 2020 at 12:55 | history | made wiki | Post Made Community Wiki by maple_shaft♦ | ||
| Dec 4, 2017 at 22:04 | comment | added | Dan Mills | IR = Intermediate Representation, compiler geek speak for anything that lies between the stuff the human is supposed to edit and machine code. | |
| Dec 4, 2017 at 20:19 | comment | added | Nakilon | What is "IR"?.. | |
| Dec 4, 2017 at 13:45 | history | edited | Dan Mills | CC BY-SA 3.0 | Corrected book title. |
| Dec 2, 2017 at 11:58 | comment | added | Dan Mills | Yea, "Structure and interpretation" indeed. My memory is clearly going. | |
| Dec 2, 2017 at 10:17 | comment | added | Giorgio | "Structure and organisation of computer programs": Did you mean "Structure and Interpretation of Computer Programs" (mitpress.mit.edu/sicp/full-text/book/book.html)? | |
| Dec 1, 2017 at 2:40 | comment | added | dmckee --- ex-moderator kitten | "they are usually happier working in marketing" Catty, but funny. | |
| Nov 29, 2017 at 16:58 | comment | added | Dan Mills | I don't disagree, but there is a cost to using an IR closer to the metal, not only in reduced generality, but in the fact that you usually end up responsible for more of the really annoying low level optimisation. The fact that we generally these days think in terms of optimising algorithm choice rather then implementation is a reflection on just how far compilers have come, sometimes you have to go really close to the metal in these things, but think twice before throwing away the compilers ability to optimise by using too low level an IR. | |
| Nov 29, 2017 at 16:38 | comment | added | Daniel Pryden | Oh, I totally agree: my comment was in response to your final paragraph questioning why you'd ever output bytecode or some lower-level thing -- sometimes you do need the lower level. (In Java specifically, there are a lot of useful things you can do with bytecode that you can't do in the Java language itself.) | |
| Nov 29, 2017 at 14:29 | comment | added | Dan Mills | But X86 assembly language makes a poor IR when targeting an ARM or PPC core! All things are a tradeoff in engineering, thats why they call it Engineering. One would hope that the possibilities of the Java bytecode were a strict superset of the possibilities of the Java language, and that this is generally true as you get closer to the metal irrespective of toolchain and where you inject the IR. | |
| Nov 29, 2017 at 14:21 | comment | added | Daniel Pryden | This is good, but I'd add that there is a tradeoff when determining which IR to use: using C as an IR makes some things easier and other things harder, when compared to, say, x86 assembly language. The choice is even more significant when choosing between, say, Java language code and Java bytecode, as there are many more operations that only exist in one or the other language. | |
| Nov 29, 2017 at 14:16 | history | answered | Dan Mills | CC BY-SA 3.0 |