Anonymous user
Languages: Difference between revisions
m
→Warning: Fixed grammar / flow
| [unchecked revision] | [unchecked revision] |
m (→Warning: Fixed grammar / flow) |
|||
| (14 intermediate revisions by 7 users not shown) | |||
Line 5:
Early operating systems were written entirely in the [[Assembly]] language dialect of their respective CPU, and it remains an option for current developers willing to put in the time and effort to use it. Even when an OS is written primarily in a high-level language, there are still parts that can only be done in assembly. A significant sub-set of OS devs choose to work exclusively in assembly, and at least some work in machine language directly (though this is rare today).
Many high-level languages have been used for OS development in the past, including [[C]], Forth, Lisp, [[CSharp|C#]], [[C++]], Modula-2, [[Ada]], Bliss, Smalltalk, and PL/1. However, not all languages as are suited for OS development, and in many languages other than C, a fair amount of Assembly development is required in order to provide the appropriate runtime environment supporting the language's abstractions. Languages such as C, Modula-2, Ada, Bliss, PL/M, and XPL have all been designed specifically for the purpose of low-level systems programming, either in OS dev or embedded systems, while languages such as Forth incorporate the necessary low-level features even when they weren't intended specifically for this purpose.
== Warning ==
Not all languages are suited for low-level system programming
Using a language other than C entails a good deal of extra effort. But there are [[Alta Lang |some developers]] who are willing to put in that effort in order to suit the development of their OSes to their ways of thinking (for example: [https://en.wikipedia.org/wiki/Programming_paradigm programming paradigms]).
Line 40:
== But I heard of an OS written in language XYZ, isn't it interpreted? ==
This is a red herring. There is no such thing as an "interpreted language".
You may from time to time hear of operating systems written in languages which are usually interpreted, or which used an interpreter of some sort: JavaOS, [http://en.wikipedia.org/wiki/Genera_%28operating_system%29 Genera] (the Symbolics Lisp Machine OS), Pilot-OS (the system for the [https://en.wikipedia.org/wiki/
* The operating system runs in a low-level interpreter, written in Assembly or some systems language like C, which is what actually interacts with the hardware. In effect, the 'operating system' is just an application running on top of another, lower-level OS. Pilot-OS, UCSD Pascal, and some Java OSes work like this, though they also have some modules which are compiled to native code as well (see below).
* All or part of the code has been compiled to native code. This may involve using a sub-set of the language with reduced runtime requirements (e.g., [http://www.citeulike.org/user/hamish/article/201596 Pre-Scheme], or [http://www.squeak.org/features/vm.html Slang] - while they have not been used for OS development to date, they do demonstrate this sort of low-level implementation language which can be used this way).
** '''Forth'''-based operating systems are a special case of this. While Forth is usually described as an interpreted language, the [http://en.wikipedia.org/wiki/Threaded_code threaded-code interpreters] many FORTH systems use work differently from most other interpreters; in effect, the interpreter walks through the various Forth 'words' that the code is comprised of until it reaches the low-level words that are implemented in assembly or compiled code, which is what actually gets executed. Furthermore, Forth systems incorporate a special sort of assembler, which produces code specifically meant to be used by the interpreter; also, commonly used 'words' can be compiled into native code as needed. Finally, many embedded Forth systems use special-purpose hardware (see below) to support the language.
** Most '''Lisp''' systems freely mix interpreted and compiled code, and in nearly all 'serious' Lisp systems since the late 1970s, the Listener REPL (the 'command line' for the Lisp system) is not an interpreter, but rather a compile-and-go system - each piece of code is at least partially compiled on the fly. While no significant Lisp OS has been made without also using language-specific hardware support (see below), if one were, it surely would not
* The system ran on specialized hardware and microcode, which acted as hardwired 'interpreter' for it's primary language, or for the portable bytecode which it normally used. This type of system includes the SOAR (Smalltalk On A RISC), the Recursiv System, The Lillith Modula-2 System, and the Burroughs 6500 (a mainframe designed for running Algol-60 in the 1960s). The system programming techniques for these cannot work on stock hardware. For example:
** The '''[http://en.wikipedia.org/wiki/MIT_CADR MIT CADR] Lisp machine architecture''' had an extensive instruction set with hardware support for certain high-level operations such as type-tag checking and GC. It had a [http://en.wikipedia.org/wiki/Tagged_architecture tagged architecture] meaning that a portion of the 36-bit addressing word was designated for type information. Typically these machines had a variety of compilers including one for the system language Lisp which was capable of taking advantage of the additional instruction set.
** The '''Rekursiv Single-Board Computer''' had hardware support for a writable instruction set (that is, you could dynamically add microcode instructions) and associative memory dispatch tables for supporting object-oriented programming.
[[Category:Languages]]
[[Category:OS Development]]
| |||