Content deleted Content added
m Open access bot: doi added to citation with #oabot. |
|||
Line 5:
==Definition==
There are a wide variety of systems under this heading. The most extreme example is a Directly Executed Language (DEL), 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 compiling needed 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.
Line 54:
A further advantage is that a language implementation can be updated by updating the microcode ([[firmware]]), without requiring recompilation of an entire system. This is analogous to updating an interpreter for an interpreted language.
An advantage that's reappearing post-2000 is safety or security. Mainstream IT has largely moved to languages with type and/or memory safety for most applications.{{Cn|date=May 2023}} The software those depend on, from OS to virtual machines, leverage native code with no protection. Many vulnerabilities have been found in such code. One solution is to use a processor custom built to execute a safe high level language or at least understand types. Protections at the processor word level make attackers' job difficult compared to low level machines that see no distinction between scalar data, arrays, pointers, or code. Academics are also developing languages with similar properties that might integrate with high level processors in the future. An example of both of these trends is the SAFE<ref>{{Cite web |url=http://www.crash-safe.org/ |title=SAFE Project |access-date=2022-07-09 |archive-date=2019-10-22 |archive-url=https://web.archive.org/web/20191022221212/http://www.crash-safe.org/ |url-status=dead }}</ref> project. Compare [[language-based system]]s, where the software (especially operating system) is based around a safe, high-level language, though the hardware need not be: the "trusted base" may still be in a lower level language.
==Disadvantages==
| |||