Re: Why couldn't an operating system be written in ada

[russ lyttle <lyttlec@removegmail.com>]

On 2/27/19 2:10 PM, Shark8 wrote:
> On Tuesday, February 26, 2019 at 4:14:03 PM UTC-7, lyttlec wrote:
>> On 2/26/19 3:46 AM, Niklas Holsti wrote:
>>> On 19-02-25 23:56 , Rabican wrote:
>>>> On Saturday, July 13, 1996 at 3:00:00 AM UTC-4, Mark  McKinney wrote:
>>>>> It has been claimed that the capability to interface with other
>>>>> languages
>>>>> is a great asset to ada. Sometimes interfacing can be a tremendous
>>>>> liability. Besides the OS could perform most of work that the language
>>>>> runtime does. So why not build an OS in ADA?
>>>>
>>>> yeah why not?  anything?
>>>
>>> This has been discussed many times before in comp.lang.ada.
>>>
>>> The first question is not "why not build an OS is Ada", the first
>>> question is "why build a new OS at all"?
>>>
>>> Then, if a new OS is going to be built for some reason, we can ask which
>>> language should be used, and of course (IMO) Ada would be a strong
>>> contender. However, for larger systems, the OS must usually implement a
>>> "process" concept that goes beyond Ada tasking and provides isolation
>>> between different users and applications. This means that the OS will
>>> have a process/service-level API that is not, as such, Ada-language
>>> specific. And so the fact that the OS is implemented in Ada becomes
>>> invisible on the application level.
>>>
>>> This is not to say that an OS API specified in Ada could not be an
>>> improvement (for Ada applications) on the current OS APIs which are
>>> usually specified in C. However, such an Ada OS API could also be
>>> provided for an OS implemented in C or some other language.
>>>
>>> At present, for small, (mostly) stand-alone embedded Ada systems, the
>>> bare-machine Ada run-times are sufficient -- and they are usually
>>> written in Ada. For larger or network-connected systems, where a
>>> comprehensive OS is needed, the Ada compiler vendors often provide
>>> run-times that hide the chosen OS (say, VxWorks) from the Ada
>>> applications, making the OS implementation language irrelevant (as long
>>> as the OS works).
>>>
>>> There are of course exceptions, such as the RTEMS real-time OS/kernel
>>> which originally supported Ada run-times but for which I believe there
>>> is today no vendor-supplier Ada run-time, which means that Ada projects
>>> that choose to use RTEMS (for some unfathomable reason) have to bind to
>>> the RTEMS C-level services directly.
>>>
>>>> can ada do CSP?
>>>
>>> Your question is rather vague, but the answer is almost certainly "yes"
>>> -- the Ada rendez-vous is very similar to an (unbuffered) Occam channel.
>>>
>> As to why write an OS in Ada, read Bruce Schneier's book "Click Here to
>> Kill Everybody". There is a need for an OS that can be proven correct
>> and can be scaled down to SBC size. Only a small subset of Ada would be
>> required to write the kernel. For example, Tasks are not needed to write
>> a kernel, nor are any POSIX features.
>> As far as I can tell, the only candidate language for writing such an OS
>> are Ada and Fortran. (Not too sure about Fortran.)
> 
> Tasks would be ideal for a nice chunk OS design, especially considering the move to multicore architectures.
> 
I mean that the kernel should provide tasking, but tasks would not be 
required to write the kernel. It's a bit off topic for an Ada group, but 
just what would a kernel with native multi-core support look like?