High-level language computer architecture: Difference between revisions

Revision as of 23:24, 20 September 2018

Revision as of 22:09, 30 October 2018

Line 58:

A detailed critique is given in {{harvtxt|Ditzel|Patterson|1980}}.

The simplest reason for the lack of success of HLLCAs is that from 1980 [[optimizing compiler]]s resulted in much faster code and were easier to develop than implementing a language in microcode. Many compiler optimizationoptimizations require complex analysis and rearrangement of the code, so the machine code is very different from the original source code. These optimizations are either impossible or impractical to implement in microcode, due to the complexity and the overhead. Analogous performance problems have a long history with interpreted languages (dating to Lisp (1958)), only being resolved adequately for practical use by [[just-in-time compilation]], pioneered in [[Self (programming language)|Self]] and commercialized in the [[HotSpot]] [[Java virtual machine]] (1999).

The fundamental problem is that HLLCAs only simplify the [[Code generation (compiler)|code generation]] step of compilers, which is typically a relatively small part of compilation, and a questionable use of computing power (transistors and microcode). At the minimum tokenization is required, and typically syntactic analysis and basic semantic checks (unbound variables) will still be performed – so there is no benefit to the front end – and optimization requires ahead-of-time analysis – so there is no benefit to the middle end.