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!aioe.org!.POSTED.c3XWybhZ9OU+TlzE1Y2ytw.user.gioia.aioe.org!not-for-mail From: russ lyttle Newsgroups: comp.lang.ada Subject: Re: Why couldn't an operating system be written in ada Date: Wed, 27 Feb 2019 14:51:26 -0500 Organization: Aioe.org NNTP Server Message-ID: References: <4s8rud$9j3@tribune> <792fba1b-7a54-4d00-ae85-e6bd0737f001@googlegroups.com> <1d9e7148-cc7d-423b-9c4a-2372d1af4ddd@googlegroups.com> NNTP-Posting-Host: c3XWybhZ9OU+TlzE1Y2ytw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:55706 Date: 2019-02-27T14:51:26-05:00 List-Id: 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?