comp.lang.ada
 help / color / mirror / Atom feed
From: lyttlec <lyttlec@removegmail.com>
Subject: Re: Why couldn't an operating system be written in ada
Date: Tue, 26 Feb 2019 18:13:58 -0500
Date: 2019-02-26T18:13:58-05:00	[thread overview]
Message-ID: <q54h7l$dmm$1@gioia.aioe.org> (raw)
In-Reply-To: gdkcmuF7b4gU1@mid.individual.net

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.)


  parent reply	other threads:[~2019-02-26 23:13 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-07-13  0:00 Why couldn't an operating system be written in ada Mark McKinney
1996-07-15  0:00 ` Nasser Abbasi
1996-07-15  0:00   ` Robert Dewar
1996-07-17  0:00     ` Randy Greene
1996-07-17  0:00   ` Hannes Haug
1996-07-15  0:00 ` David Wheeler
1996-07-15  0:00   ` Michael Levasseur
1996-07-25  0:00     ` Greg Harvey
1996-07-26  0:00       ` Kent Mitchell
1996-07-16  0:00   ` Poutanen Olavi
1996-07-15  0:00 ` Jon S Anthony
1996-07-15  0:00   ` Brian Rogoff
1996-07-15  0:00   ` Mark Eichin
1996-07-16  0:00   ` Jon S Anthony
2019-03-02 16:07   ` Optikos
2019-03-03 22:14     ` russ lyttle
2019-01-10 23:38 ` cenci.br
2019-01-10 23:54   ` Lucretia
2019-04-07  1:55   ` Nick Roberts
2019-04-07  4:32     ` Optikos
2019-04-07 10:35       ` Nick Roberts
2019-04-07 14:06         ` Optikos
2019-01-14 11:26 ` George Shapovalov
2019-02-25  2:25   ` russ lyttle
2019-03-09 18:43     ` Norman Worth
2019-02-25 21:56 ` Rabican
2019-02-26  8:46   ` Niklas Holsti
2019-02-26  9:30     ` Dmitry A. Kazakov
2019-02-26 23:32       ` lyttlec
2019-02-27  2:00         ` Dennis Lee Bieber
2019-02-27  6:20           ` russ lyttle
2019-02-27  8:26             ` Dmitry A. Kazakov
2019-02-27 13:54               ` russ lyttle
2019-02-27 15:55                 ` Dmitry A. Kazakov
2019-02-27 16:46                   ` russ lyttle
2019-02-27 23:52                   ` Randy Brukardt
2019-02-27  8:20         ` Dmitry A. Kazakov
2019-02-27 14:06           ` russ lyttle
2019-02-27 14:23             ` Niklas Holsti
2019-02-27 16:01             ` Dmitry A. Kazakov
2019-02-27 17:04               ` russ lyttle
2019-02-27 17:29                 ` Dmitry A. Kazakov
2019-03-09 18:46         ` Norman Worth
2019-02-26 23:13     ` lyttlec [this message]
2019-02-27 19:10       ` Shark8
2019-02-27 19:51         ` russ lyttle
2019-02-27 22:12           ` Niklas Holsti
2019-03-01 15:07             ` fabien.chouteau
2019-02-27 10:47 ` Patrick Jakubowski
2019-02-28  6:23   ` G. B.
2019-02-28  8:28     ` Simon Wright
  -- strict thread matches above, loose matches on Subject: below --
1996-07-15  0:00 Simon Johnston
1996-07-15  0:00 Robert C. Leif, Ph.D.
1996-07-17  0:00 ` wfranck
1996-07-17  0:00 ` Mark McKinney
1996-07-20  0:00   ` Michael Feldman
1996-07-22  0:00     ` Theodore E. Dennison
1996-07-22  0:00       ` Larry Kilgallen
1996-07-30  0:00       ` Pascal Martin @lone
1996-08-01  0:00         ` Bob Kitzberger
1996-08-03  0:00           ` Pascal Martin @lone
1996-07-17  0:00 ` wfranck
1996-07-22  0:00   ` Felicia R. Rosemond (214)-462-5371 ple1 SE
1996-07-29  0:00     ` Wallace E. Owen
1996-07-19  0:00 Marin David Condic, 407.796.8997, M/S 731-93
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox