4 ms·
>> In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, O
by adwn 12y ago
>> In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.
> No, because I have listed Ada in my list.
I have no idea how that would refute my statement.
> Better improve your CS skills.
Don't be so condescending.
> Oberon GC in Oberon
I stand corrected: You're right, the GC runtime for a language with non-optional GC can be written in the language itself.
I guess a better, more precise indicator are the following two requirements:
1) Native support for calling OS services, for example through system calls (specifically, reservation of memory space).
2) Pointers, pointer arithmetic, and reading/writing memory through pointers.
I don't see how one could implement the GC runtime without these features. (Note that native support for heap-allocation means that GC is optional anyway). What do you think?
- pjmlp 12y ago> I have no idea how that would refute my statement Ada is used for building systems running on bare metal. > Native support for calling OS services, for example through system calls (specifically, reservation of memory space). 2) Pointers, pointer arithmetic, and reading/writing memory through pointers. Oberon variants and Modula-3 support GC pointers and have been used to write full OSs. Pointer arithmetic is possible in code regions marked as unsafe. The Oberon based ones were used for several years at Swiss Federal Institute of Technology. Spin (Modula-3) didn't had such luck, as DEC and Olivetti got closed down. Just read the code provided in the link for Oberon's example. The problem is that many think GC == Java, while during the years Java was getting loose into the world, there where languages like Cedar, Oberon and Modula-3 that while having a GC do offer the fine grain control one needs for system programming. > Note that native support for heap-allocation means that GC is optional anyway Not really. In safe systems programming language the GC is always there and you need to mark the code as unsafe when allocating from foreign heap. Meaning you are responsible for not tainting the whole code base. For example, in the Oberon OS only the Kernel and driver modules do manual allocation. Actually, Java 9 is getting the missing features from safe systems programming languages (some of them will only come in Java 10).