From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Why couldn't an operating system be written in ada Date: Tue, 26 Feb 2019 10:46:22 +0200 Organization: Tidorum Ltd Message-ID: References: <4s8rud$9j3@tribune> <792fba1b-7a54-4d00-ae85-e6bd0737f001@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net vk0/7qjwZBkOFj0JygdqlgmQutQI8OqkBPzxFI59AKLZgg1D7N Cancel-Lock: sha1:U8gotwQYMtena28b+kqyyu0kZgA= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <792fba1b-7a54-4d00-ae85-e6bd0737f001@googlegroups.com> Xref: reader01.eternal-september.org comp.lang.ada:55667 Date: 2019-02-26T10:46:22+02:00 List-Id: 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .