High-level language computer architecture: Difference between revisions

Revision as of 05:56, 11 December 2021

Revision as of 10:19, 12 December 2021

Line 1:

A '''high-level language computer architecture''' ('''HLLCA''') is a [[computer architecture]] designed to be targeted by a specific [[high-level programming language]] (HLL), rather than the architecture being dictated by hardware considerations. It is accordingly also termed '''language-directed computer design,''' coined in {{harvtxt|McKeeman|1967}} and primarily used in the 1960s and 1970s. HLLCAs were popular in the 1960s and 1970s, but largely disappeared in the 1980s. This followed the dramatic failure of the [[Intel 432]] (1981) and the emergence of [[optimizing compiler]]s and [[reduced instruction set computer]] (RISC) architectures and RISC-like [[complex instruction set computer]] (CISC) architectures, and the later development of [[just-in-time compilation]] for HLLs. A detailed survey and critique can be found in {{harvtxt|Ditzel|Patterson|1980}}.

HLLCAs date almost to the beginning of HLLs, in the [[Burroughs large systems]] (1961), which were designed for [[ALGOL 60]] (1960), one of the first HLLs. The mostbest well-known HLLCAs aremay be the [[Lisp machine]]s of the 1970s and 1980s, (for the language [[Lisp (programming language)|Lisp]], (1959). At present the most popular HLLCAs are [[Java processor]]s, for the language [[Java (programming language)|Java]] (1995), and these are a qualified success, being used for certain applications. A recent architecture in this vein is the [[Heterogeneous System Architecture]] (2012), which [[HSA Intermediate Layer]] (HSAIL) provides instruction set support for HLL features such as exceptions and virtual functions; this uses JIT to ensure performance.

==Definition==

There are a wide variety of systems under this heading. The most extreme example is a Directly Executed Language, where the [[instruction set architecture]] (ISA) of the computer equals the instructions of the HLL, and the [[source code]] is directly executable with minimal processing. In extreme cases, the only compilationcompiling requiredneeded is [[tokenizing]] the source code and feeding the tokens directly to the processor; this is found in [[stack-oriented programming language]]s running on a [[stack machine]]. For more conventional languages, the HLL statements are grouped into instruction + [[Parameter (computer programming)|arguments]], and [[Infix notation|infix]] order is transformed to [[Substring|prefix]] or [[Reverse Polish notation|postfix]] order. DELs are typically only hypothetical, though they were advocated in the 1970s.<ref>See Yaohan Chu references.</ref>

In less extreme examples, the source code is first parsed to [[bytecode]], which is then the [[machine code]] that is passed to the processor. In these cases, the system typically lacks an [[Assembly language|assembler]], as the [[compiler]] is deemed sufficient, though in some cases (such as Java), assemblers are used to produce legal bytecode which would not be output by the compiler. This approach was found in the [[Pascal MicroEngine]] (1979), and is currently used by Java processors.

More loosely, a HLLCA may simply be a general-purpose computer architecture with some features specifically to support a given HLL or several HLLs. This was found in Lisp machines from the 1970s onward, which augmented general-purpose processors with operations specifically designed to support Lisp.

Line 60:

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 optimizations 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 (virtual machine)|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 requiredneeded, 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.

A deeper problem, still an active area of development {{as of|2014|lc=1}},<ref>See [[LLVM]] and the Clang compiler.</ref> is that providing HLL debugging information from machine code is quite difficult, basically because of the overhead of debugging information, and more subtly because compilation (particularly optimization) makes determining the original source for a machine instruction quite involved. Thus the debugging information provided as an essential part of HLLCAs either severely limits implementation or adds significant overhead in ordinary use.

Further, HLLCAs are typically optimized for a singleone language, supporting other languages more poorly. Similar issues arise in multi-language virtual machines, notably the Java virtual machine (designed for Java) and the .NET [[Common Language Runtime]] (designed for [[C Sharp (programming language)|C#]]), where other languages are second-class citizens, and often must hew closely to the main language in semantics. For this reason lower-level ISAs allow multiple languages to be well-supported, given compiler support. However, a similar issue arises even for many apparently language-neutral processors, which are well-supported by the language [[C (programming language)|C]], and where [[source-to-source compiler|transpiling]] to C (rather than directly targeting the hardware) yields efficient programs and simple compilers.

The advantages of HLLCAs can be alternatively achieved in HLL Computer ''Systems'' ([[language-based system]]s) in alternative ways, primarily via compilers or interpreters: the system is still written in a HLL, but there is a trusted base in software running on a lower-level architecture. This has been the approach followed since circa 1980: for example, a Java system where the runtime environment itself is written in C, but the operating system and applications written in Java.

==Alternatives==

Since the 1980s the focus of research and implementation in general-purpose computer architectures has primarily been in RISC-like architectures, typically internally register-rich [[load/storeload–store architecture]]s, with rather stable, non-language-specific ISAs, featuring multiple registers, pipelining, and more recently multicore systems, rather than language-specific ISAs. Language support has focused on compilers and their runtimes, and interpreters and their virtual machines (particularly JIT'ing ones), with little direct hardware support. For example, the current [[Objective-C]] runtime for iOS implements [[tagged pointer]]s, which it uses for type-checking and garbage collection, despite the hardware not being a tagged architecture.

In computer architecture, the RISC approach has proven very popular and successful instead, and is opposite from HLLCAs, emphasizing a very simple instruction set architecture. However, the speed advantages of RISC computers in the 1980s was primarily due to early adoption of [[on-chip cache]] and room for large registers, rather than intrinsic advantages of RISC .{{Citation needed|date=October 2019}}.

==See also==

Line 84:

{{reflist}}

{{refbegin}}

* {{cite conference |last=McKeeman title|first=William M. |date=November 14–16, 1967 |title=Language directed computer design | url = http://www.computer.org/csdl/proceedings/afips/1967/5070/00/50700413.pdf| first = William M.| last = McKeeman| author-link = William M. McKeeman| conference = AFIPS '67 (Fall) Proceedings of the November 14–16, 1967, Fall Joint Computer Conference | volume = 31|date=1967}}

** {{Cite journal | last = Keirstead | first = Ralph E. | date=March 1968 | title = R68-8 Language Directed Computer Design | journal = IEEE Transactions on Computers | volume = 17 | issue = 3 | pages = 298 | url = http://www.computer.org/csdl/trans/tc/1968/03/01687335.pdf | doi = 10.1109/TC.1968.229106 | s2cid = 41983403 }} – review

* {{Cite proceedings | last1 = Ditzel | first1 = David R. | last2 = Patterson | first2 = David A. |author-link2= David Patterson (computer scientist) | year = 1980 | title = Retrospective on High-Level Language Computer Architecture | conference = ISCA '80 Proceedings of the 7th annual symposium on Computer Architecture | pages = 97–104 | publisher = ACM | doi = 10.1145/800053.801914 | url = http://courses.cs.washington.edu/courses/cse548/05wi/files/Ditzel-Retrospective-on-HLL-Computer-Architecture.pdf |access-date= 2014-11-18 }}

* ''[http://www.tkt.cs.tut.fi/kurssit/3520/K13/CH_3.pdf A Baker’s Dozen: Fallacies and Pitfalls in Processor Design]'' Grant Martin & Steve Leibson, [[Tensilica]] (early 2000s), slides 6–9

{{refend}}

Line 92:

==Further reading==

{{refbegin}}

* ''{{Cite thesis |type=PhD |last=Wortman |first=David Barkley |date=1972 |title=A Study of Language Directed Computer Design,'' David Barkley Wortman, |publisher=Department of Computer Science, Ph.D. thesis, Stanford University, 1972}}

* {{Cite journal | last = Hoevel | first = L.W. | date=August 1974 | title = "Ideal" Directly Executed Languages: An Analytical Argument for Emulation | journal = IEEE Transactions on Computers | volume = 23 | issue = 8 | pages = 759–767 | publisher = IEEE | doi = 10.1109/T-C.1974.224032 | s2cid = 29921112 | url = https://digital.library.unt.edu/ark:/67531/metadc1022942/m2/1/high_res_d/4310455.pdf }}

* {{Cite journal | last = Chu | first = Yaohan | date=December 1975 | title = Concepts of high-level-language computer architecture | journal = ACM SIGMICRO Newsletter | volume = 6 | issue = 4 | pages = 9–16 | doi = 10.1145/1217196.1217197 | s2cid = 9545539 }}

** {{Cite conference | last = Chu | first = Yaohan | year = 1975 | title = Concepts of high-level-language computer architecture | conference = ACM '75 Proceedings of the 1975 annual conference | pages = 6–13 | doi = 10.1145/800181.810257}}

* {{Cite journal | last1 = Chu | first1 = Yaohan | last2 = Cannon | first2 = R. | date=June 1976 | title = Interactive High-Level Language Direct-Execution Microprocessor System | journal = IEEE Transactions on Software Engineering | volume = 2 | issue = 2 | pages = 126–134 | doi = 10.1109/TSE.1976.233802 | s2cid = 9076898 }}

* {{Cite journal | last = Chu | first = Yaohan | date=December 1977 | title = Direct-execution computer architecture | journal = ACM SIGARCH Computer Architecture News | volume = 6 | issue = 5 | pages = 18–23 | doi = 10.1145/859412.859415 | s2cid = 10241380 }}

* {{Cite conference | last = Chu | first = Yaohan | year = 1978 | title = Direct Execution In A High-Level Computer Architecture | conference = ACM '78 Proceedings of the 1978 annual conference | pages = 289–300 | doi = 10.1145/800127.804116}}

* {{Cite journal | last1 = Chu | first1 = Yaohan | last2 = Abrams | first2 = M. | date=July 1981 | title = Programming Languages and Direct-Execution Computer Architecture | journal = Computer | volume = 14 | issue = 7 | pages = 22–32 | doi = 10.1109/C-M.1981.220525 | s2cid = 3373193 }}

{{refend}}