`LIL is, however, a failure. Its stiffest competition at Bell Labs is the language C, which is higher level, and machine independent. Every time it looked like C was too expensive to use for a particular project, LIL was considered. But almost every time, it proved easier (and more rewarding) to improve C, or its runtime support, or the hardware, than to invest time in yet another language. ... A machine independent language is always superior -- even for writing machine dependent code (it's easier to find trained programmers) -- so long as the overhead can be endured. It is clear now that writing straightforward code and then measuring it is the formula for the best end product. At worst there will be 5-15 per cent overhead, which is seldom critical. Once system writers become mature enough to recognize this basic truth, they gravitate naturally toward machine independent SILs. ... it looks like the little implementation language is an idea whose time as come -- and gone.`
I would not say that this approach is definitely a failure. Let's consider the following possible uses of it.
1. UNCOL-like language. Now we have LLVM IR and this is basically the same old UNCOL with all its bad points. Still, due to help of the large companies and with supporting only a subset of possible processor architectures this "LIL" variant is quite popular.
2. An assember with algebraic syntax. This is really good thing to have, much more readable than all those cryptic mnemonics. Here are few interesting examples: DSP assemblers [1] and [2], low-level DSLs [3]. I'm using algebraic notation in my own compilers. There is a trivial mapping between low-level term-based IR and C-like algebraic assembly source (in some cases you even don't need to have a separate simulator, just compile the code with C compiler).
`LIL is, however, a failure. Its stiffest competition at Bell Labs is the language C, which is higher level, and machine independent. Every time it looked like C was too expensive to use for a particular project, LIL was considered. But almost every time, it proved easier (and more rewarding) to improve C, or its runtime support, or the hardware, than to invest time in yet another language. ... A machine independent language is always superior -- even for writing machine dependent code (it's easier to find trained programmers) -- so long as the overhead can be endured. It is clear now that writing straightforward code and then measuring it is the formula for the best end product. At worst there will be 5-15 per cent overhead, which is seldom critical. Once system writers become mature enough to recognize this basic truth, they gravitate naturally toward machine independent SILs. ... it looks like the little implementation language is an idea whose time as come -- and gone.`