Why couldn't an operating system be written in ada

Why couldn't an operating system be written in ada

[Mark McKinney]

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?

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

[Mark Eichin]

>   A neat idea whose time is long since gone.  The OS "wars" have been fought
>   and largely lost.... :-(

Well, the users lost anyway :-}  However, research certainly
continues -- and there need to be good arguments against doing OS
research using fragile, difficult to read languages like C...

MK, VSTA, and other operating systems exist to serve as research
platforms (and sometimes as operational platforms when "modern" 70's
and 80's systems just can't cut it.)  Surely there is justification
for using Ada in this context, at least?

I brought up this point with a well known linux kernel developer, and
between the two of us we came up with several things that I didn't
know Ada95 well enough to answer:
	1) Can you do efficient raw memory operations (ie. raw byte
arrays, explicit control of when an access can be eliminated, and no
overhead [or at least, not stored in-place, for an object like a page
or a video card?]
	2) Can you interface efficiently to machine code
(ie. equivalent of inline asm, where you *mostly* can code a high
level algorithm but the core needs to be a particular hardware level
instruction. A GNAT-specific answer is ok, in this case...)
	3) Can you work without tasking (since you're implementing the
scheduler!) [I'll take arguments that you should in fact use Ada
tasking within the kernel, if they're detailed...]
	4) Can you do complete memory management (without garbage
collection.) 

As you can see, I *don't* know much Ada, though I've gotten a start on
Barnes' excellent "Ada95" text.  My guesses are that (1) is possible,
but you must go out of your way to do it; (2) might be possible in
GNAT; (3) is probably obvious and (4) is true but the reasoning is
subtle.

I haven't thought of any other potential obstacles to OS work in Ada;
it would seem a good choice, based on the *intent* of the design, but
I can't yet judge the results.

					_Mark_ <eichin@cygnus.com>
					Cygnus Support, Eastern USA

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

[Michael Levasseur]

The first Rational machines had an OS written in Ada. There
were some problems with the Disk Subsystem but overall the
system was ahead of its time. The one thing that was most 
memorable about the system was that it had in excess of
300 keys. Anyone who's ever seen the old Rational System
knows about their keyboard.

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

[Brian Rogoff]

jsa@organon.com (Jon S Anthony) writes:
   In article <4s8rud$9j3@tribune> Mark  McKinney <mckmark@mail.concentric.net> writes:

   > liability. Besides the OS could perform most of work that the language 
   > runtime does. So why not build an OS in ADA?

   A neat idea whose time is long since gone.  The OS "wars" have been fought
   and largely lost.... :-(

I disagree. The PC desktop war looks over to me (Win 95 / Win NT) but there 
are lots of other markets open and opening. And a pure research OS, or a 
freeware OS like Linux, is always a neat idea to me :-). In fact I bet there 
are quite a few OO-OSs written in C++ that could have been written in 
Ada 95.

-- Brian

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

[Nasser Abbasi]

   From: Mark  McKinney <mckmark@mail.concentric.net>


   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?
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The question should be: why build another OS ? we allready have
too many.

bye the way, I saw a book many years ago, where some people
did develop some sort of operating system in Ada83, offcourse
it was a research type OS system, not a "real" commercial
one, do not know now the name of the book, but it was around
1988 or so. 

Building a "real" OS is a very large job, it takes years and years,
with large teams of people working on it, and very few companies
can committ to something like this very easily regardless of the
language used.

Nasser


-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
Perkin Elmer - Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM (Fide Chess Master).

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

[Robert Dewar]

Nasser said

"Building a "real" OS is a very large job, it takes years and years,
with large teams of people working on it, and very few companies
can committ to something like this very easily regardless of the
language used."

Building a full OS, including all utilities, compilers, etc is indeed
a very large job, but building just the kernel is not such a  big job
(Linux for instance is NOT that large). So building an OS kernel
in Ada would be a reasonably practical project.

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

[Jon S Anthony]

In article <4s8rud$9j3@tribune> Mark  McKinney <mckmark@mail.concentric.net> writes:

> liability. Besides the OS could perform most of work that the language 
> runtime does. So why not build an OS in ADA?

A neat idea whose time is long since gone.  The OS "wars" have been fought
and largely lost.... :-(

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[David Wheeler]

Mark  McKinney (mckmark@mail.concentric.net) 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?

The BiiN system had an OS written in Ada, as well as a number of
other interesting capabilities (fault-tolerance, capability-based
security, etc.).  However, developing the OS, hardware, and other things
was incredibly costly, and the sales didn't ramp up fast enough
to overcome the $$ invested.

Real OS's are time-consuming to create.


--- David A. Wheeler
Net address: wheeler@ida.org

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

[Robert C. Leif, Ph.D.]

The following appeared on Comp.Lang.Ada
----------------------------------------------------------------------------
-------------
Date:    Mon, 15 Jul 1996 02:12:25 GMT
From:    Nasser Abbasi <nasser@APLDBIO.COM>
Subject: Re: Why couldn't an operating system be written in ada

   >From: Mark  McKinney <mckmark@mail.concentric.net>


  Mark  McKinney> > 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?
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Nasser Abbasi >The question should be: why build another OS ? we already have
>too many.
----------------------------------------------------------------------------
-------------------------
The question, "So why not build an OS in ADA"? requires more than a yes or
no response.

Firstly, one should define, what constitutes an operating system. Then, one
should determine what parts will be improved by recreating and redesigning
them in Ada.

Since Windows is the best selling operating system, I will take the liberty
of offending some of you by defining an operating system as what one
purchases when buying Windows. This is NOT meant as an endorsement of
Microsoft's code.

Component               Should be Ada       Comment
---------------                 ---------------------
Executive (core).          Yes
GUI                                 Needs a binding.
Device Drivers              Use off the shelf. If not available,  create in Ada.
Applets                          Use what is provided.
File System                   Use what is provided, and if necessary, add
Ada enhancements.
Ada POSIX Binding     Would help.

Executive: I suspect that for both real-time systems and pseudo embedded
systems where the operating system only runs one application. These include
medical instruments and other dedicated devices.

GUI: I would prefer a thick binding for my applications. The use of some
standard to permit portability will greatly help. My present guess is that
HTML will be the successful portable solution.

Device Drivers: A major real advantage of Windows is the availability of
device drivers. Parenthetically, the major disadvantage of Ada is the lack
of device drivers for boards, such as analog to digital converters,
printers, and high resolution displays.

The only applets from Windows, where Ada would obviously help are those to
do with communication. Applets such as games, screen savers, and file viewers

The Windows 95 Explorer is a great improvement. However, a database based
system would be a further improvement.

Ada POSIX bindings would increase portability. I quite well understand that
it is probably too costly to provide a complete POSIX binding. However,
where possible, the Ada POSIX binding syntax should be employed. The
exceptions: Can_Not_Be_Implemented or Not_Implemented probably will need to
be created and used fairly often.

Lastly, I wish to emphasize that the present GUIs are often far beyond the
capabilities of most users. Many individuals, including some of considerable
ability in other fields, are still quite happy with DOS applications, such
as WordPerfect. A 32 bit version of DOS might still be a profitable enterprise.

Robert C. Leif, Ph.D.

Robert C. Leif, Ph.D., PMIAC,
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
Tel. & Fax (619) 582-0437

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

[Simon Johnston]

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?

Check out RTEMS at the very least!

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,-------------------------------------------------------------------------.
--|Simon K. Johnston - Development Engineer (C++/Ada95) |ICL Retail Systems |
--|-----------------------------------------------------|3/4 Willoughby Road|
--|Unix Mail: skj@acm.org                               |Bracknell          |
--|Telephone: +44 (0)1344 476320 Fax: +44 (0)1344 476302|Berkshire          |
--|Internal : 7261 6320   OP Mail: S.K.Johnston@BRA0801 |RG12 8TJ           |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom     |
--`-------------------------------------------------------------------------'
end Sig;

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

[Poutanen Olavi]

The Nokia MPS 10 machine was all built around Ada. Its OS and all other
subsystems were written in Ada. The hardware architecture was prorietary,
"home designed". The instruction set and Ada run-time system were to some
extent desingned hand-by-hand putting the implementation to that side where
it was most convenient/efficient.

This effort took place in Finland at Nokia Data System roughly around the
years 1979..1987. This machine was supposed to become a  winner, to contain
the most advanced techniques and ideas. At the early 80's Ada was one of
those. I personally was involved in the MPS 10 effort primariliy as being
in charge of the RDBMS system implemented in Ada (see Proceedings of the
Ada Europe 1985, Paris) and of some Ada testing tools (Ada Europe 1987,
Stockholm and Quality Week 1993, San Francisco).

Nokia Data, today known as ICL Data (Nokia Corp sold its computer
manufacturing branch to ICL Plc/UK sometimes 1990), had been a leading
provider of bank systems (3-tier architechture) to Finnish banks. The
previous solution was based (branch office computers) on also Nokia-
proprietary Mikko-3 computers.

I remember one special argumentation in favor of Ada in that business
situtation: It was envisioned (at early 80's) that the future is in open
architectures and standard hardware solutions. Perhaps the banks won't buy
a yet another system upgrade where they should again build all their
applications from scratch. Ada and its portability was supposed to help
here, as a means to carry the applications to the new platform.

The next platform came soon: Intel 80286/386(/486) and OS/2. We bravely
tried to get an Ada environment into OS/2. But due to various reasons Ada
really didn't take off on that environment at Nokia.

Anyways, the MPS 10 machine has been in use in a couple of Finnish banks
for many years (as a branch office server having certain responsibility of
the overall system). It was not many years ago when I still saw those
machines, don't know if there are any more in production use.

Once the bugs and inefficiencies of the MPS 10 systems were ironed away and
the usage got stabilized, it was amazing with how little maintenance staff
the support could be managed.

On peak years the development staff was c. 200 people. Today they are still
either at ICL doing the Team OFFICE product or at Nokia Corp doing
telecommunications or mobile phones software.

Just my 2 Eurocents...

- Olavi
-------------------- *** Code hard, test well! *** ------------------------
Olavi Poutanen                                     E-mail: olavip@cs.tut.fi
Testwell Oy                                        Tel:    +358-31-316-5464
Kanslerinkatu 8, FIN-33720 Tampere, Finland        Fax:    +358-31-318-3311
(After 12 Oct 1996 00:00 use Tel: +358-3-316-5464, Fax: +358-3-318-3311)
---------------------------------------------------------------------------

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

[Jon S Anthony]

In article <xe1687p1cha.fsf@maneki-neko.cygnus.com> Mark Eichin <eichin@cygnus.com> writes:

> > A neat idea whose time is long since gone.  The OS "wars" have
> > been fought and largely lost.... :-(
> 
> Well, the users lost anyway :-}  However, research certainly

Yeah, that's what I meant...


> MK, VSTA, and other operating systems exist to serve as research
> platforms (and sometimes as operational platforms when "modern" 70's
> and 80's systems just can't cut it.)  Surely there is justification
> for using Ada in this context, at least?

I'm sure there is all sorts of good reasons to use Ada in these
contexts.  But, the results will probably never see the light of day -
maybe a peek or two...


> I brought up this point with a well known linux kernel developer, and
> between the two of us we came up with several things that I didn't
> know Ada95 well enough to answer:
> 	1) Can you do efficient raw memory operations (ie. raw byte
> arrays, explicit control of when an access can be eliminated, and no
> overhead [or at least, not stored in-place, for an object like a page
> or a video card?]

Yes, this should not be any sort of a problem.  With
System.Storage_Elements and address clauses and such you should be
well covered.


> 	2) Can you interface efficiently to machine code
> (ie. equivalent of inline asm, where you *mostly* can code a high
> level algorithm but the core needs to be a particular hardware level
> instruction. A GNAT-specific answer is ok, in this case...)

Sure.  Actually this sort of thing is defined in the language with
convention intrinsic (6.3.1) and System.Machine_Code (13.8).


> 	3) Can you work without tasking (since you're implementing the
> scheduler!) [I'll take arguments that you should in fact use Ada
> tasking within the kernel, if they're detailed...]

Sure you can.  But to my mind, it would make as much (or more) sense
to first create the tasking kernel and then build the OS scheduler on
top of this.  This seems like the most straightforward way to proceed
and it has the added benefit that you can use "regular tasking" in
other parts of the OS design and know that you will not be interfering
in some nefarious way with the OS scheduler.  I'm sure there is
probably a reason why you might not want to do this, but it isn't
obvious to me.


> 	4) Can you do complete memory management (without garbage
> collection.) 

Sure.  You can define your own storage pools (System.Storage_Pools)
and write specific MM operations for them.  This way you can have
different styles of AMM for different sorts of "objects" - thereby
allowing the most "appropriate" technique for the resource type.  See
13.11


> As you can see, I *don't* know much Ada, though I've gotten a start on
> Barnes' excellent "Ada95" text.

Yes, for knowledgeable types, outside the RM and Rationale, I would
say Barnes is the best thing going.

>  My guesses are that (1) is possible,
> but you must go out of your way to do it; (2) might be possible in
> GNAT; (3) is probably obvious and (4) is true but the reasoning is
> subtle.

(1): Really rather straight forward and not that big of a deal
(2): Easily done.
(3): Yes, obvious
(4): Really pretty obvious also.  The subtlty comes in how clever the
     AMMs you write are.


> I haven't thought of any other potential obstacles to OS work in Ada;
> it would seem a good choice, based on the *intent* of the design, but
> I can't yet judge the results.

Well, one way to look at it is that since (one of) the primary areas
of intended use for Ada was and is "real-time"/embedded systems, OS
sort of work should "just fall right out".  Access to HW, interrupts,
and that sort of bare machine stuff is defined in the language (well,
the annexes anyway...)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Randy Greene]

Robert Dewar wrote:
> 
> Nasser said
> 
> "Building a "real" OS is a very large job, it takes years and years,
> with large teams of people working on it, and very few companies
> can committ to something like this very easily regardless of the
> language used."
> 
> Building a full OS, including all utilities, compilers, etc is indeed
> a very large job, but building just the kernel is not such a  big job
> (Linux for instance is NOT that large). So building an OS kernel
> in Ada would be a reasonably practical project.

My 2 cents...

I agree with Robert that the effort to build an OS kernel in Ada is 
not unreasonably large. The part of Hughes Aircraft that I work for 
has been writing real-time embedded OSs in Ada since 1988, the latest 
having been developed for the F-22 figher. These OSs support multiple 
programs, multi-threaded processes, separate virtual address spaces 
for each program, Multi-level security, etc., and, even with all the 
I/O drivers, these OSs have tended to run around 25,000 lines of code 
or smaller (maybe 15,000 for the kernel itself). This isn't so large 
that its beyond the scope of one person to write. My experience is 
that the other tools needed for a "full" system (compiler, linker, 
debugger, etc.) tend to take far more effort than the kernel itself.


Randy Greene
Hughes Aircraft Company
Radar and Communications Systems

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

[Hannes Haug]

>>>>> "Robert" == Robert Dewar <dewar@cs.nyu.edu> writes:

    Robert> Nasser said
    Robert> "Building a "real" OS is a very large job, it takes years and
    Robert> years, with large teams of people working on it, and very few
    Robert> companies can committ to something like this very easily regardless
    Robert> of the language used."

    Robert> Building a full OS, including all utilities, compilers, etc is
    Robert> indeed a very large job, but building just the kernel is not such
    Robert> a  big job (Linux for instance is NOT that large). So building an
    Robert> OS kernel in Ada would be a reasonably practical project.

Perhaps the just released Flux Operating System Toolkit
(http://www.cs.utah.edu/projects/flux/oskit/html/) can be used.
A hello word kernel is probably a weekend project. But I might
be wrong.

 -hannes

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

[wfranck]

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

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

[wfranck]

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

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

[Mark McKinney]

So far its a big job and there is no or little market seem to be the only 
resons. Although this is certainly prohibitive, are there any technical 
reasons it can't be done. I'm not really interested in money or time as a 
constraint. It's purely academic.

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

[Marin David Condic, 407.796.8997, M/S 731-93]

Robert Dewar <dewar@CS.NYU.EDU> writes:
>
>Building a full OS, including all utilities, compilers, etc is indeed
>a very large job, but building just the kernel is not such a  big job
>(Linux for instance is NOT that large). So building an OS kernel
>in Ada would be a reasonably practical project.
>
    Actually, when you think about it, almost every embedded system
    built in Ada is - or contains - an "operating system" written in
    Ada. Most embedded systems have an "executive" (or something
    similar) which controls I/O, schedules applications, handles
    security, etc. Granted, it's not as sophisticated (generally) as
    something like VMS or WindowsNT, but they are quite often more
    advanced than what might have passed for an "operating system"
    back in the late 70's.

    Just my 2c worth.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
   "I'm just glad it'll be Clark Gable who's falling on his face and
    not Gary Cooper."

        --  Gary Cooper on his decision not to take the leading role in
            "Gone With  The Wind."
===============================================================================

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

[Michael Feldman]

In article <4shjeg$5jk@herald.concentric.net>,
Mark  McKinney  <mckmark@mail.concentric.net> wrote:
>So far its a big job and there is no or little market seem to be the only 
>resons. Although this is certainly prohibitive, are there any technical 
>reasons it can't be done. I'm not really interested in money or time as a 
>constraint. It's purely academic.

If it's an academic project that you'd be doing for curiosity, I say
"go for it." Depending on how much you know already about OS functionality,
you could start by studying the source code for Minix, or even Linux
for that matter, then designing your Ada OS.

I agree with the other writers that there is little or no commercial
reason for an Ada clone of an existing, supported, OS. Why reinvent
the wheel? Why fix what isn't broken?

There is surely no reason why an OS can't be done in Ada, all the way
down to the metal.

Mike Feldman

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

[Theodore E. Dennison]

Michael Feldman wrote:
> 
> I agree with the other writers that there is little or no commercial
> reason for an Ada clone of an existing, supported, OS. Why reinvent
> the wheel? Why fix what isn't broken?


Well...it would plug up quite a few of UNIX's security holes.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

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

[Larry Kilgallen]

In article <31F37B86.41C67EA6@escmail.orl.mmc.com>, "Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes:
> Michael Feldman wrote:
>> 
>> I agree with the other writers that there is little or no commercial
>> reason for an Ada clone of an existing, supported, OS. Why reinvent
>> the wheel? Why fix what isn't broken?
> 
> 
> Well...it would plug up quite a few of UNIX's security holes.

But then it might not be Unix.

What some of us security advocates see as "holes", long-term Unix
advocates see as "features".

At some point one has changed the operating characteristics of an
environment so much that it is no longer the same operating system.
I think with Unix that time might come sooner rather than later.

Larry Kilgallen

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

[Felicia R. Rosemond (214)-462-5371 ple1 SE]

dsfkjfdfgvlkjdfb

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

[Greg Harvey]

Michael Levasseur wrote:
> The first Rational machines had an OS written in Ada. There
> were some problems with the Disk Subsystem but overall the
> system was ahead of its time. The one thing that was most 
> memorable about the system was that it had in excess of
> 300 keys. Anyone who's ever seen the old Rational System
> knows about their keyboard.

The story is better than this, of course.  Rational offered an odd-looking
terminal that was longer in the vertical direction than in the horizontal. 
The display system would then divide this pure-text terminal into separate
windows.  Each window could then be used to display various kinds of
interesting information such as "file system" structure, code that you were
editing, and various kinds of status.

All of the navigation of this system (which was written BY programmers FOR
programmers) was done with the 300+ keys.  To accomplish 300+ keys, of
course, you have to have key modifiers such as ctrl, meta, hyper, etc.  I
don't recall the names of the keys on the terminals RATIONAL sold, but I do
remember having one of the programmers on my team working the problem of
connecting the Rational to different platforms via telnet-style
connections.

Don Silvasi-Patchin did the work, and it was a beautiful work of art. 
Since we were doing this for NASA (Software Support Environment for Space
Station Freedom), we of course were expected to produce remarkably similar
keymaps for all supported platforms which included VT100-compatible
terminals, PC's, Mac, and Apollo (don't ask how those became the
standards...that is a separate post).  

Don spent about 3 months massaging the Delta environment until it would in
most cases properly recognize which terminal emulator was hitting it and
respond in a reasonable fashion.   He also spent a lot of time figuring out
how he could do he could do the keymaps so that a person who was familiar
with them on one computer would have a shallow learning curve if they had
to work with them on another computer.  The result was then written up and
put onto oversized "pocket cards" which prominently displayed the SSE logo.
 It really was a NICE solution to a tricky problem.

The result?  SSE didn't really use the Rationals much for programming
because the cross-machine targeting issues were trickier than originally
imagined.  Because Rational had a product that helped with 2167A
documentation, the sites that had Rationals tried to use them to produce
the volumes and volumes of SSF design documents.  This of course was not
what the Rational was designed to do, so it took up all available machine
resources.

This of course prevented what little programming that WAS done on the
Rational from getting done in any reasonable time frame, which pushed
people onto Unix and PC boxes for development and compiling.  Rational
caused the demise of their own machine by supporting documentation on it.

Getting back to the keymaps, the funny thing was, since only the main SSE
project had much of a mixture of machines, in spite of spending 3 months of
programmer effort on building a standard keymap, the work package
contractors tended to rely on the original, Rational keymap for VT100
because:  a)  they had learned it first, and b) it was "good enough".

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

[Kent Mitchell]

Greg Harvey (gharvey@rwi.com) wrote:

: This of course prevented what little programming that WAS done on the
: Rational from getting done in any reasonable time frame, which pushed
: people onto Unix and PC boxes for development and compiling.  Rational
: caused the demise of their own machine by supporting documentation on it.

Well ... this is not exactly true.  While the SSE document generation didi
drag a whole machine, they were far and away some of the most complicated
documents I've ever seen (and worthless for any real purpose other than
satisfying a contractual obligation).  Most of our customers were quite
successfull using our documentation generation capabilites.  It's not
what "caused the demise of (our) machine".

The machines went away because Rational could not afford to keep up with
the IBM, Sun and  Intel's of the world on hardware performance.  That
coupled with the demand for open systems was too great for a
custom hardware/software solution to fly.  I think our Apex solution is
superior to our old systems *and* on standard hardware/os.  

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

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

[Wallace E. Owen]

In article <31F3E61E.41C67EA6@dseg.ti.com>,
Felicia R. Rosemond (214)-462-5371 ple1 SE <felicia@dseg.ti.com> wrote:
>dsfkjfdfgvlkjdfb

I see your point.


  // Wally

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

[Pascal Martin @lone]

Let be a little technical here, and come back to the original point.

Alsys, then Thomson Software Products, have almost always implemented the
Ada runtime for bare targets in (a subset of) Ada. This is what I know as
the closest approximation of an OS.

The Ada standard assumes the following ressources as granted: tasking, heap,
exceptions, io (too name a few).

One of the purpose of the OS is to provide tasking, so breaking the "egg and
chicken" problem imply prohibiting use of the tasking within the OS kernel
code. Not a big problem by itself, but a new set of tasking primitives will
have to be defined for kernel internal use. A good point could be using
a (very) simplified implementation of protected records.

The Ada heap is a nice but complicated piece of code. It could be reused for
an OS, except that it does not comply with MMU or DMA requirements. A lower
memory management level is to be implemented (and the Ada heap should be
rebuilt on top of it). The Ada heap is also protected against concurrency.
This is nice to have, but depends on the Ada tasking internals. Some
adaptations would be required.

One problem is the Ada type system. An OS constantly switch from one level
of abstraction to another: for example, it reads a disk block, and then
understands it as a directory content. With its strong type system, Ada is
not comfortable at that (any comment ??). With its weak type system, C let
the user do all the mistakes he never wanted to do. An usual solution is
to make extensive use of System.Address: programming in Ada with a C style.
Not only it is as unsafe as C, but Ada make things a little more ugly than C.
The best work-around I have ever found is using array-of-bytes buffers and
then use the address clause to map a more typed view. Looks too much like C.
Beware of aliasing and alignment problems !

What we need in an OS would be a language with some controled 'type morphing'
features. Modula 2 included some basic morphing (with its predefined 'generic'
types: BYTE, WORD, ..). A good academic subject ?

Exceptions are good for many things. I would promote use of exceptions in
an OS. But the Ada 95 exceptions raise multiple concerns when STORAGE_ERROR
is raised, because the exception occurence stuff may require use of dynamic
structures. This is a huge problem in an OS which must survive to memory
ressources limitations. So I would recommend using only a subset of the
exceptions features.

If you look back at these restrictions, you will find out that most of them
imply using a specific, reduced, implementation of the runtime. But each
compiler comes with its own (specific) runtime, and runtime interfaces.
Any solution will be compiler-specific and involve building your own 'Ada'
environment (runtime) first. This is not really Ada anymore. This environment
will be the lower layer of the OS kernel. The rest of the OS (drivers, file
systems, network, ..) could be built on top of it.

In France the SOL project intended to build a Unix clone in Pascal (ISO
version). The founding came from the French ministry of defense, because
of export restriction on US products. Eventually, SOL came to life, but
they was forced to define their own variant of Pascal (and managed to get
it adopted as an AFNOR standard--the French equivalent of ANSI), so they
could still claim using a 'standard' Pascal. SOL was not really better
than Unix version 7, and could not keep on competing with BSD. This is
a dead thing now. A lesson to learn ?

The final lesson is Ada has never been designed for such a purpose, obviously.
This has probably never been part of the DOD requirements, anyway.

Pascal Martin.

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

[Bob Kitzberger]

Pascal Martin @lone (pmartin@alsys.com) wrote:

: One of the purpose of the OS is to provide tasking, so breaking the "egg and
: chicken" problem imply prohibiting use of the tasking within the OS kernel
: code. Not a big problem by itself, but a new set of tasking primitives will
: have to be defined for kernel internal use. 

Once you bootstrap the tasking kernel though, you can rewrite the
tasking support using itself, though.

:-) :-) :-)

(a little Ada compiler/kernel implementation humor... _very_ little!)


--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

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

[Pascal Martin @lone]

In article <4tr8op$fvd@rational.rational.com>, rlk@pelton (Bob Kitzberger) writes:
>Pascal Martin @lone (pmartin@alsys.com) wrote:
>
>: One of the purpose of the OS is to provide tasking, so breaking the "egg and
>: chicken" problem imply prohibiting use of the tasking within the OS kernel
>: code. Not a big problem by itself, but a new set of tasking primitives will
>: have to be defined for kernel internal use. 
>
>Once you bootstrap the tasking kernel though, you can rewrite the
>tasking support using itself, though.
>
>:-) :-) :-)
>

You have programmed in Lisp most of your life, don't you ? :-) I cannot wait
for seeing a rational product implementing this Meta-Tasking concept !.

Pascal.

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

[cenci.br]

Em sábado, 13 de julho de 1996 04:00:00 UTC-3, Mark  McKinney  escreveu:
> 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?

Is this discussion still active ?

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

[Lucretia]

On Thursday, 10 January 2019 23:38:22 UTC, cenc...@gmail.com  wrote:
> Em sábado, 13 de julho de 1996 04:00:00 UTC-3, Mark  McKinney  escreveu:
> > 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?
> 
> Is this discussion still active ?

Given, this was from 1996, I'd say not. Just start a new thread if you want to ask/know something.

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

[George Shapovalov]

Well, gnat is built on top of gcc, so you have implicit Ada integration with the gcc toolchain and even Posix bindings to assist is some tasks. So, strictly speaking, nothing stops someone from starting to replace Linux/BSD kernel internals one module at a time :) (you would have, of course, to operate within the no-RTL limitation). Having maintained gnat in Gentoo Linux I can attest to feasibility of at least small tweaks and general compatibility.. 
Of course you would have to prove the merit of such replacement to the larger community, presenting extra stability/maintainability or utility sufficient to overcome the resistance to the unknown new thing.

Also, @Pascal Martin mentions some very nice points about tasking and heap management. Unix has a different tasking model, so direct substitution is not an option, but I suppose a superset and bindings could be provided. This and all others are, however, tedious and time consuming tasks. Especially the community handling aspect. But at least this way you have some "point of entry". Creating a complete new and not tied to established standards OS may be possible (even if resource hungry). But making people actually use it (to any significant extent, rather than playing with it for all of 1hr, even when provided for free) would be much more complicated..

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

[russ lyttle]

On 1/14/19 6:26 AM, George Shapovalov wrote:
> Well, gnat is built on top of gcc, so you have implicit Ada integration with the gcc toolchain and even Posix bindings to assist is some tasks. So, strictly speaking, nothing stops someone from starting to replace Linux/BSD kernel internals one module at a time :) (you would have, of course, to operate within the no-RTL limitation). Having maintained gnat in Gentoo Linux I can attest to feasibility of at least small tweaks and general compatibility..
> Of course you would have to prove the merit of such replacement to the larger community, presenting extra stability/maintainability or utility sufficient to overcome the resistance to the unknown new thing.
> 
> Also, @Pascal Martin mentions some very nice points about tasking and heap management. Unix has a different tasking model, so direct substitution is not an option, but I suppose a superset and bindings could be provided. This and all others are, however, tedious and time consuming tasks. Especially the community handling aspect. But at least this way you have some "point of entry". Creating a complete new and not tied to established standards OS may be possible (even if resource hungry). But making people actually use it (to any significant extent, rather than playing with it for all of 1hr, even when provided for free) would be much more complicated..
> 
Actually, I once wrote a small operating system in ada'83. I was just 
about to ask here if someone had done the same thing in a more modern 
version. Think of an Ada version of uCOS. A generic cross-compiler or 
IDE that accepts a profile of the target hardware might be needed.

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

[Rabican]

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? 
Rmox from university kent in Uk loosk awesome
can ada do CSP?

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

[Niklas Holsti]

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

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

[Dmitry A. Kazakov]

On 2019-02-26 09:46, 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.

Right. This is a general problem only tangentially related to Ada. The 
purely procedural OS API outlived their time.

A new generation of OSes must have higher-level API which would include 
tasking and synchronization primitives as well as other abstract types 
types. Call it OO or not, but that is beyond procedures, ints and void *.

The world is not ready for this and the languages, Ada included, are not 
mature enough either.

So, yes, one can write an C-esque OS in Ada, but who needs yet another 
horse cart?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[lyttlec]

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

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

[lyttlec]

On 2/26/19 4:30 AM, Dmitry A. Kazakov wrote:
> On 2019-02-26 09:46, 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.
> 
> Right. This is a general problem only tangentially related to Ada. The
> purely procedural OS API outlived their time.
> 
> A new generation of OSes must have higher-level API which would include
> tasking and synchronization primitives as well as other abstract types
> types. Call it OO or not, but that is beyond procedures, ints and void *.
> 
> The world is not ready for this and the languages, Ada included, are not
> mature enough either.
> 
> So, yes, one can write an C-esque OS in Ada, but who needs yet another
> horse cart?
> 
Often overlooked is that any "C-esque" POSIX compliant OS turns the
computer into a VAX. C was written to be easily translated into VAX
machine code and POSIX signals are all the original interrupts on a VAX.
If you have a CISC computer running VMS, C is your language.

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

[Dennis Lee Bieber]

On Tue, 26 Feb 2019 18:32:12 -0500, lyttlec <lyttlec@removegmail.com>
declaimed the following:

>Often overlooked is that any "C-esque" POSIX compliant OS turns the
>computer into a VAX. C was written to be easily translated into VAX
>machine code and POSIX signals are all the original interrupts on a VAX.
>If you have a CISC computer running VMS, C is your language.

	Pardon? The C language predates the VAX architecture by over half a
decade, if not more. The language was created ~1972 (as a derivative of
BCPL via the language B); it was PDP-7, followed by PDP-11.

	The VAX-11/780 was released near the end of 1977.

	Oh, and the high-level systems language used for the VMS OS just
happens to be BLISS https://en.wikipedia.org/wiki/BLISS .

	Both predate POSIX (1988).


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

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

[russ lyttle]

On 2/26/19 9:00 PM, Dennis Lee Bieber wrote:
> On Tue, 26 Feb 2019 18:32:12 -0500, lyttlec <lyttlec@removegmail.com>
> declaimed the following:
> 
>> Often overlooked is that any "C-esque" POSIX compliant OS turns the
>> computer into a VAX. C was written to be easily translated into VAX
>> machine code and POSIX signals are all the original interrupts on a VAX.
>> If you have a CISC computer running VMS, C is your language.
> 
> 	Pardon? The C language predates the VAX architecture by over half a
> decade, if not more. The language was created ~1972 (as a derivative of
> BCPL via the language B); it was PDP-7, followed by PDP-11.
> 
> 	The VAX-11/780 was released near the end of 1977.
> 
> 	Oh, and the high-level systems language used for the VMS OS just
> happens to be BLISS https://en.wikipedia.org/wiki/BLISS .
> 
> 	Both predate POSIX (1988).
> 
> 
That is all true. You could make the case that C turns your computer 
into a PDP-11. I was being generous.

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

[Dmitry A. Kazakov]

On 2019-02-27 00:32, lyttlec wrote:

> Often overlooked is that any "C-esque" POSIX compliant OS turns the
> computer into a VAX. C was written to be easily translated into VAX
> machine code and POSIX signals are all the original interrupts on a VAX.
> If you have a CISC computer running VMS, C is your language.

What? In VMS you could call any OS primitive from *any* language without 
POSIX garbage. DEC Ada worked perfectly well doing OS calls even if you 
had no DEC C installed. Why would you ever use C if you had DEC Ada?

POSIX was nothing but one of many successful UNIX's moves to eliminate 
more advanced OSes and crush OS market.

BTW, nobody sane would ever use POSIX layer on VMS. VMS API were 
infinitely more advanced and comfortable to use in every possible 
aspect. The same can be said about Windows. However bad Windows API 
might be, POSIX Windows API is far worse and inferior. Even under Linux 
POSIX is the last resort when nothing else helps.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dmitry A. Kazakov]

On 2019-02-27 07:20, russ lyttle wrote:

> That is all true. You could make the case that C turns your computer 
> into a PDP-11. I was being generous.

Huh, you could not write

    MOV -(PC),-(PC)

in C, if I correctly remember the famous PDP-11 one-liner.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Patrick Jakubowski]

I guess it could. ADA is systems programming language.Everyone here knows how it would benefit. However some parts of the OS still are better expressed in C. Or I am wrong. I used to work on hardware accelerated network packet processing.I needed to make data structures in a way that fit in cache L1 of a processor. This was a must. Also special data handling for direct hardware only communication between multiple network interfaces. There was no place for error checking like variable range or table boundary. I know that it can be disabled in ADA. I am curious myself if I could prepare and provoke ADA to keep data structures in L1 cache.

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

[russ lyttle]

On 2/27/19 3:26 AM, Dmitry A. Kazakov wrote:
> On 2019-02-27 07:20, russ lyttle wrote:
> 
>> That is all true. You could make the case that C turns your computer 
>> into a PDP-11. I was being generous.
> 
> Huh, you could not write
> 
>     MOV -(PC),-(PC)
> 
> in C, if I correctly remember the famous PDP-11 one-liner.
> 
https://developers.slashdot.org/story/13/06/19/1227244/pdp-11-still-working-in-nuclear-plants---for-37-more-years

  In case the reader doesn't know the reference. IIRC, there was a way 
to inject that code from a C program. As one commented, the code is on a 
9-track tape somewhere.

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

[russ lyttle]

On 2/27/19 3:20 AM, Dmitry A. Kazakov wrote:
> On 2019-02-27 00:32, lyttlec wrote:
> 
>> Often overlooked is that any "C-esque" POSIX compliant OS turns the
>> computer into a VAX. C was written to be easily translated into VAX
>> machine code and POSIX signals are all the original interrupts on a VAX.
>> If you have a CISC computer running VMS, C is your language.
> 
> What? In VMS you could call any OS primitive from *any* language without 
> POSIX garbage. DEC Ada worked perfectly well doing OS calls even if you 
> had no DEC C installed. Why would you ever use C if you had DEC Ada?
> 
> POSIX was nothing but one of many successful UNIX's moves to eliminate 
> more advanced OSes and crush OS market.
> 
> BTW, nobody sane would ever use POSIX layer on VMS. VMS API were 
> infinitely more advanced and comfortable to use in every possible 
> aspect. The same can be said about Windows. However bad Windows API 
> might be, POSIX Windows API is far worse and inferior. Even under Linux 
> POSIX is the last resort when nothing else helps.
> 
Thus my desire for an OS and Ada not dependent on any POSIX layer. Still 
digging, but it looks to me like gnat depends on a POSIX layer.
Is that true?

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

[Niklas Holsti]

On 19-02-27 16:06 , russ lyttle wrote:
> On 2/27/19 3:20 AM, Dmitry A. Kazakov wrote:
>> BTW, nobody sane would ever use POSIX layer on VMS. VMS API were
>> infinitely more advanced and comfortable to use in every possible
>> aspect. The same can be said about Windows....
>>
> Thus my desire for an OS and Ada not dependent on any POSIX layer.

To me this seems like a kind of premature optimization. POSIX is not 
evil in and of itself. Presumably you will not be using VMS, so would no 
be committing the insanity Dmitry warns against.

> Still digging, but it looks to me like gnat depends on a POSIX layer.
> Is that true?

Certainly false for the AdaCore bare-metal runtimes I've seen. Those 
systems don't have any POSIX layer.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Dmitry A. Kazakov]

On 2019-02-27 14:54, russ lyttle wrote:
> On 2/27/19 3:26 AM, Dmitry A. Kazakov wrote:
>> On 2019-02-27 07:20, russ lyttle wrote:
>>
>>> That is all true. You could make the case that C turns your computer 
>>> into a PDP-11. I was being generous.
>>
>> Huh, you could not write
>>
>>     MOV -(PC),-(PC)
>>
>> in C, if I correctly remember the famous PDP-11 one-liner.
>>
> https://developers.slashdot.org/story/13/06/19/1227244/pdp-11-still-working-in-nuclear-plants---for-37-more-years 
> 
> 
>   In case the reader doesn't know the reference. IIRC, there was a way 
> to inject that code from a C program. As one commented, the code is on a 
> 9-track tape somewhere.

Maybe an anecdote. The only C compiler for PDP-11 (for RSX-11M) I 
remember was a 5-stage monster which took an half an hour to compile 
hello-world. We programmed it mostly in MACRO-11 (an incredibly powerful 
assembler/preprocessor language).

BTW, RSX-11M had pretty much powerful memory protection and 
virtualization. I remember tricks to gain an equivalent of root 
privileges, but most them were closed in late versions. All this on the 
machines with 256K RAM. If not the stupidity of management the first PCs 
could be LSI-11 based.

    https://en.wikichip.org/wiki/dec/lsi-11

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dmitry A. Kazakov]

On 2019-02-27 15:06, russ lyttle wrote:

> Thus my desire for an OS and Ada not dependent on any POSIX layer. Still 
> digging, but it looks to me like gnat depends on a POSIX layer.
> Is that true?

The GNAT RTS is capable to use pthreads if you mean that. Nothing more. 
In fact if you look at the GNAT run-time you will see lots of 
OS-specific calls. So, no GNAT RTS does not depend on POSIX.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[russ lyttle]

On 2/27/19 10:55 AM, Dmitry A. Kazakov wrote:
> On 2019-02-27 14:54, russ lyttle wrote:
>> On 2/27/19 3:26 AM, Dmitry A. Kazakov wrote:
>>> On 2019-02-27 07:20, russ lyttle wrote:
>>>
>>>> That is all true. You could make the case that C turns your computer 
>>>> into a PDP-11. I was being generous.
>>>
>>> Huh, you could not write
>>>
>>>     MOV -(PC),-(PC)
>>>
>>> in C, if I correctly remember the famous PDP-11 one-liner.
>>>
>> https://developers.slashdot.org/story/13/06/19/1227244/pdp-11-still-working-in-nuclear-plants---for-37-more-years 
>>
>>
>>   In case the reader doesn't know the reference. IIRC, there was a way 
>> to inject that code from a C program. As one commented, the code is on 
>> a 9-track tape somewhere.
> 
> Maybe an anecdote. The only C compiler for PDP-11 (for RSX-11M) I 
> remember was a 5-stage monster which took an half an hour to compile 
> hello-world. We programmed it mostly in MACRO-11 (an incredibly powerful 
> assembler/preprocessor language).
> 
> BTW, RSX-11M had pretty much powerful memory protection and 
> virtualization. I remember tricks to gain an equivalent of root 
> privileges, but most them were closed in late versions. All this on the 
> machines with 256K RAM. If not the stupidity of management the first PCs 
> could be LSI-11 based.
> 
>     https://en.wikichip.org/wiki/dec/lsi-11
> 
I agree. The structure of C with its header files, #includes, etc., was 
just to fit the compiler and chunks of program into the machine.
The process was start the compilation, go play Dungeon or Castle 
Wolfenstein or Star Trek in ascii art on a teletype for a while.

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

[russ lyttle]

On 2/27/19 11:01 AM, Dmitry A. Kazakov wrote:
> On 2019-02-27 15:06, russ lyttle wrote:
> 
>> Thus my desire for an OS and Ada not dependent on any POSIX layer. 
>> Still digging, but it looks to me like gnat depends on a POSIX layer.
>> Is that true?
> 
> The GNAT RTS is capable to use pthreads if you mean that. Nothing more. 
> In fact if you look at the GNAT run-time you will see lots of 
> OS-specific calls. So, no GNAT RTS does not depend on POSIX.
> 
I thought I was seeing POSIX Signals and Priority also.

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

[Dmitry A. Kazakov]

On 2019-02-27 18:04, russ lyttle wrote:
> On 2/27/19 11:01 AM, Dmitry A. Kazakov wrote:
>> On 2019-02-27 15:06, russ lyttle wrote:
>>
>>> Thus my desire for an OS and Ada not dependent on any POSIX layer. 
>>> Still digging, but it looks to me like gnat depends on a POSIX layer.
>>> Is that true?
>>
>> The GNAT RTS is capable to use pthreads if you mean that. Nothing 
>> more. In fact if you look at the GNAT run-time you will see lots of 
>> OS-specific calls. So, no GNAT RTS does not depend on POSIX.
>>
> I thought I was seeing POSIX Signals and Priority also.

When tasking is backed by pthreads then that is a rational choice.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Shark8]

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.

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

[russ lyttle]

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?

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

[Niklas Holsti]

On 19-02-27 21:51 , russ lyttle wrote:
> On 2/27/19 2:10 PM, Shark8 wrote:
>>
>> 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?

The AdaCore run-time system (which implements tasks) that I have looked 
at in more detail -- the Small Foot-Print Ravenscar RTS for LEON2/LEON3 
SPARCs -- has optional multicore support; it didn't seem to add much 
code/logic to the basic code. Separate "ready queues" for each core is a 
straight-forward concept.

The implementation of protected objects may have to be somewhat 
different. In a single-core system, mutual exclusion can be implemented 
by the "ceiling priority" method, but that doesn't work in multi-core 
systems, so more conventional locks must likely be used.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:q56bt3$kbn$1@gioia.aioe.org...
...
> Maybe an anecdote. The only C compiler for PDP-11 (for RSX-11M) I remember 
> was a 5-stage monster which took an half an hour to compile hello-world. 
> We programmed it mostly in MACRO-11 (an incredibly powerful 
> assembler/preprocessor language).

I used the Unix C compiler on PDP-11s as an undergrad at the University of 
Wisconsin circa 1978. Indeed, that compiler was the the cause of my lifelong 
distaste for the language. It semed to have only two error messages "LValue 
expected" at compile-time and "bus error, core dumped" at runtime. It was 
the root of the only student project that I didn't complete successfully on 
time (some wild array uses caused it to malfunction during the demo - I was 
so pissed that I spent 5 hours debugging it afterwards, which is why I know 
exactly what went wrong).

Putting 30 students on a PDP-11 was madness, with pretty slow compiles at 
times. (Especially bad when your compile didn't finish before your timeslot 
was done and you had to give up your terminal for the next person. I 
discovered that the 2 am slots were rarely used and ended up doing projects 
then so I could worrk until done.)

The school got VAXes the next year.

                                 Randy.

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

[G. B.]

Patrick Jakubowski <patrick.jakubowski@googlemail.com> wrote:
>  I am curious myself if I could prepare and provoke ADA to keep data
> structures in L1 cache.
> 

You can. (I wouldn‘t know, though, how to have the ADA (organization) store
things in a cache.) The idea is that Ada (the language) lets the programmer
express, with relative ease, what needs to be known to safely disable
checks. And then, also, the run-time system can be minimized, even zeroed.

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

[Simon Wright]

G. B. <nonlegitur@nmhp.invalid> writes:

> Patrick Jakubowski <patrick.jakubowski@googlemail.com> wrote:
>>  I am curious myself if I could prepare and provoke ADA to keep data
>> structures in L1 cache.
>> 
>
> You can. (I wouldn‘t know, though, how to have the ADA (organization)
> store things in a cache.) The idea is that Ada (the language) lets the
> programmer express, with relative ease, what needs to be known to
> safely disable checks. And then, also, the run-time system can be
> minimized, even zeroed.

I found a paper on cache-conscious data structures[1], which was much
more interested in locality than in detailed representation. If you have
a large data structure, better to have the 'hot' parts of an individual
node in a smaller object, so they stand more chance of getting into the
same cache line, with the 'cold' parts kept elsewhere.

Looked like a lot of work, it'd have to be worth it.

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/ccds.pdf

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

[fabien.chouteau]

I implemented the SMP support in Ravenscar. You are right in you analysis.

On Wednesday, February 27, 2019 at 11:12:18 PM UTC+1, Niklas Holsti wrote:
> The implementation of protected objects may have to be somewhat 
> different. In a single-core system, mutual exclusion can be implemented 
> by the "ceiling priority" method, but that doesn't work in multi-core 
> systems, so more conventional locks must likely be used.
> 

We use "fair locks" to keep a constant worst case access to the protected object.

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

[Optikos]

On Monday, July 15, 1996 at 3:00:00 AM UTC-4, Jon S Anthony wrote:
> In article <4s8rud$9j3@tribune> Mark  McKinney <mckmark@mail.concentric.net> writes:
> 
> > liability. Besides the OS could perform most of work that the language 
> > runtime does. So why not build an OS in ADA?
> 
> A neat idea whose time is long since gone.  The OS "wars" have been fought
> and largely lost.... :-(

As true today in 2019 as it was in 1996, when Linux was just starting to dominate over the incumbent Unixes for mindshare.

If one seeks to write an operating system that mimics the behavior of other existing OSes but is merely rewritten in Ada as minor implementation nit, then it is an effort doomed to failure unless you are a billionaire looking for a fascinating hobby project.

The OS wars in recent years has reached a truce of sorts with everyone converging on Linux (for now).  What a next-gen OS must do is solve one or more pernicious problems faced by today's OS+cloud that is ill served by today's OS's and orchestration.  Don't solve the same problem again (but done right).  Rather solve a new problem that obsoletes Linux and today's haphazard cloud infrastructure and today's AI and today's self-driving automobile neural nets and today's telecom networking and ubiquitous FPGAs everywhere and ubiquitous physics-modeling-processors (i.e., GPUs) everywhere and software-defined networking (SDN) and software-defined WAN (SD-WAN) and software-defined data center and … and … and.

The old Sun Microsystems' advertising tagline is more true today than it was back in the 1990s when their ads plastered it everywhere:  “The network is the computer.”  Today, in the microcosm, we have a many-core confederation of cache-coherent NUMA processors & cores therein in an all-hardware-protocol network.  Plus in the macrocosm, we have cloud computing based on either VMs (KVM mainly, with a smattering of VMware).  A new OS would focus on doing all of these things differently than today and better than today in one over-arching well-thought-out vision.

We don't need a new OS per se.  We need an entirely different OS with an entirely different mission.

We don't need a new successor to Ada per se (that placates troglodyte syntax preferences).  We need Ada to have a new mission.  Randy's Ada2020 interest in bringing a Rust-esque borrow checker to Ada is a hint in this direction of a drastically new mission for Ada.

Once your mind's eye sees the new unified mission clearly (as Francis Corbató did for General Electric in Multics during the late 1960s), the gaps to fill to get us there become far less mysterious and, more importantly, far less mundane & pedestrian.  Then expandedAda has a newMegaOS to go solve well to eclipse the incumbent Linux+orchestration+cobbled-together-self-driving-automobile+AI+GPUs+ubiquitous-FPGAs hodgepodge that is the current lackluster state of disarray in computing.  The expandedAda as the implementation language of newOS could marshal far more than Linux does today.  And that is what an OS does:  •marshaling complexity•, whether it is called scheduling or orchestration or I/O or impeccably-perfect resource lifetime.

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

[russ lyttle]

On 3/2/19 11:07 AM, Optikos wrote:
> On Monday, July 15, 1996 at 3:00:00 AM UTC-4, Jon S Anthony wrote:
>> In article <4s8rud$9j3@tribune> Mark  McKinney <mckmark@mail.concentric.net> writes:
>>
>>> liability. Besides the OS could perform most of work that the language
>>> runtime does. So why not build an OS in ADA?
>>
>> A neat idea whose time is long since gone.  The OS "wars" have been fought
>> and largely lost.... :-(
> 
> As true today in 2019 as it was in 1996, when Linux was just starting to dominate over the incumbent Unixes for mindshare.
> 
> If one seeks to write an operating system that mimics the behavior of other existing OSes but is merely rewritten in Ada as minor implementation nit, then it is an effort doomed to failure unless you are a billionaire looking for a fascinating hobby project.
> 
> The OS wars in recent years has reached a truce of sorts with everyone converging on Linux (for now).  What a next-gen OS must do is solve one or more pernicious problems faced by today's OS+cloud that is ill served by today's OS's and orchestration.  Don't solve the same problem again (but done right).  Rather solve a new problem that obsoletes Linux and today's haphazard cloud infrastructure and today's AI and today's self-driving automobile neural nets and today's telecom networking and ubiquitous FPGAs everywhere and ubiquitous physics-modeling-processors (i.e., GPUs) everywhere and software-defined networking (SDN) and software-defined WAN (SD-WAN) and software-defined data center and … and … and.
> 
> The old Sun Microsystems' advertising tagline is more true today than it was back in the 1990s when their ads plastered it everywhere:  “The network is the computer.”  Today, in the microcosm, we have a many-core confederation of cache-coherent NUMA processors & cores therein in an all-hardware-protocol network.  Plus in the macrocosm, we have cloud computing based on either VMs (KVM mainly, with a smattering of VMware).  A new OS would focus on doing all of these things differently than today and better than today in one over-arching well-thought-out vision.
> 
> We don't need a new OS per se.  We need an entirely different OS with an entirely different mission.
> 
> We don't need a new successor to Ada per se (that placates troglodyte syntax preferences).  We need Ada to have a new mission.  Randy's Ada2020 interest in bringing a Rust-esque borrow checker to Ada is a hint in this direction of a drastically new mission for Ada.
> 
> Once your mind's eye sees the new unified mission clearly (as Francis Corbató did for General Electric in Multics during the late 1960s), the gaps to fill to get us there become far less mysterious and, more importantly, far less mundane & pedestrian.  Then expandedAda has a newMegaOS to go solve well to eclipse the incumbent Linux+orchestration+cobbled-together-self-driving-automobile+AI+GPUs+ubiquitous-FPGAs hodgepodge that is the current lackluster state of disarray in computing.  The expandedAda as the implementation language of newOS could marshal far more than Linux does today.  And that is what an OS does:  •marshaling complexity•, whether it is called scheduling or orchestration or I/O or impeccably-perfect resource lifetime.
> 
Exactly!  Even though the current buzz-word is "cloud", an OS is needed 
for massively networked heterogeneous CPUs. To mis-quote Bruce Schneier, 
a car is a computer with wheels. In fact, it is a big computer composed 
of many smaller computers interconnected as nodes on networks. An OS is 
needed that is native to that environment and treats all nodes as part 
of itself. As far as I can tell, the only language available today in 
which that OS could be written is Ada with (perhaps) Ravenscar and 
Spark. That is, if the Ada team decides to accept the mission.

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

[Norman Worth]

russ lyttle wrote:
> On 1/14/19 6:26 AM, George Shapovalov wrote:
>> Well, gnat is built on top of gcc, so you have implicit Ada 
>> integration with the gcc toolchain and even Posix bindings to assist 
>> is some tasks. So, strictly speaking, nothing stops someone from 
>> starting to replace Linux/BSD kernel internals one module at a time :) 
>> (you would have, of course, to operate within the no-RTL limitation). 
>> Having maintained gnat in Gentoo Linux I can attest to feasibility of 
>> at least small tweaks and general compatibility..
>> Of course you would have to prove the merit of such replacement to the 
>> larger community, presenting extra stability/maintainability or 
>> utility sufficient to overcome the resistance to the unknown new thing.
>>
>> Also, @Pascal Martin mentions some very nice points about tasking and 
>> heap management. Unix has a different tasking model, so direct 
>> substitution is not an option, but I suppose a superset and bindings 
>> could be provided. This and all others are, however, tedious and time 
>> consuming tasks. Especially the community handling aspect. But at 
>> least this way you have some "point of entry". Creating a complete new 
>> and not tied to established standards OS may be possible (even if 
>> resource hungry). But making people actually use it (to any 
>> significant extent, rather than playing with it for all of 1hr, even 
>> when provided for free) would be much more complicated..
>>
> Actually, I once wrote a small operating system in ada'83. I was just 
> about to ask here if someone had done the same thing in a more modern 
> version. Think of an Ada version of uCOS. A generic cross-compiler or 
> IDE that accepts a profile of the target hardware might be needed.
Operating systems have been written Ada; you just have never seen or 
heard of them because they have been small projects, either academic or 
for specialized uses.  Not all operating systems are Posix complaint, or 
have user interfaces, or support multiple users.  What constitutes an 
operating system may be an issue here.  At its most basic, it is just a 
program that provides certain common utility functions.  It is often 
often a good idea to write (or adapt from the many that are already out 
there) a bare bones operating system to handle IO and dispatching for 
embedded systems. (Ada tasking takes care of dispatching pretty well, 
but IO is another matter.)  Somebody had a project to write a fully 
Posix compliant, BSD-like operating system a few years ago, but I don't 
know if it was ever finished.  The Posix standard is very C oriented, so 
this might be a challenge.

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

[Norman Worth]

lyttlec wrote:
> On 2/26/19 4:30 AM, Dmitry A. Kazakov wrote:
>> On 2019-02-26 09:46, 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.
>>
>> Right. This is a general problem only tangentially related to Ada. The
>> purely procedural OS API outlived their time.
>>
>> A new generation of OSes must have higher-level API which would include
>> tasking and synchronization primitives as well as other abstract types
>> types. Call it OO or not, but that is beyond procedures, ints and void *.
>>
>> The world is not ready for this and the languages, Ada included, are not
>> mature enough either.
>>
>> So, yes, one can write an C-esque OS in Ada, but who needs yet another
>> horse cart?
>>
> Often overlooked is that any "C-esque" POSIX compliant OS turns the
> computer into a VAX. C was written to be easily translated into VAX
> machine code and POSIX signals are all the original interrupts on a VAX.
> If you have a CISC computer running VMS, C is your language.
> 
Actually, C was written for the PDP-6, long before the VAX.  It was used 
at AT&T to write UNIX for that machine, long before VMS.

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

[Nick Roberts]

On 10/01/2019 23:38, cenci.br@gmail.com wrote:
> Em sábado, 13 de julho de 1996 04:00:00 UTC-3, Mark  McKinney  escreveu:
>> 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?
> 
> Is this discussion still active ?

I have a little bit of a plan for this, but I must admit it is very 
ambitious. The biggest problem I face is getting help, as well as my own 
lack of skill in running these projects.

My current plan goes along these lines:

I am building a new Ada compiler that will use a new technology for 
targeting machine architectures. The following is a simplification, but 
it gives the gist of it.

1. The compiler builds Ada source text into an intermediary code, called 
'PXC' (a kind of abbreviation for 'extended pseudo-code'). These PXC 
files are distributed to the target machines. Each PXC file is a module, 
and a complete program comprises many such modules (perhaps hundreds of 
them, or even thousands).

2. Each target machine itself has a program called the Realizor, which 
generates a real executable file, comprising actual machine code for the 
architecture of its own processor(s), from the complete set of PXC 
modules that go to make up the program.

One of the big advantages of doing it this way is that global 
optimisations, including inlining of cross-module calls, can be 
performed by the Realizor. In addition, the Realizor can implement a 
strategy of capturing profiling data (execution statistics) for the 
program, and periodically re-realising it to yield still better 
optimisations.

3. Because of the way the Realizor works, all privilege level-changing 
calls (e.g. into the kernel) can be removed. Security is, nevertheless, 
fully maintained.

(I also intend the technology to remove all use of hardware paging; this 
will be replaced by a more intelligent software-based segment-swapping 
mechanism.)

4. Because of 3 above, it is possible for the kernel and all the device 
drivers and other low-level software to be PXC modules, mixed in by the 
Realizor along with all the other PXC modules. This means that many 
kernel calls can be inlined, effectively eliminating all call overhead 
on them.

I believe these technologies would enable a dedicated piece of software, 
running 24/7, to run significantly faster.

When you consider how important performance is on today's vast farms of 
servers, that could be a pretty compelling reason for people to switch 
from traditional operating systems.

All I have to do is to do it :-)



I'm hoping it could be a way of getting Ada back into the mainstream. We 
all know in this forum that building future software in Ada, especially 
server software, would be a big step towards making it more secure and 
reliable.

PS: There's a lot more about this scheme that I would like to say, but I 
don't want to turn this post into a dissertation, and I do want to get 
to bed soon. If you have any burning questions, please ask.

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

[Optikos]

On Saturday, April 6, 2019 at 9:55:21 PM UTC-4, Nick Roberts wrote:
> On 10/01/2019 23:38, cenci.br@gmail.com wrote:
> > Em sábado, 13 de julho de 1996 04:00:00 UTC-3, Mark  McKinney  escreveu:
> >> 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?
> > 
> > Is this discussion still active ?
> 
> I have a little bit of a plan for this, but I must admit it is very 
> ambitious. The biggest problem I face is getting help, as well as my own 
> lack of skill in running these projects.
> 
> My current plan goes along these lines:
> 
> I am building a new Ada compiler that will use a new technology for 
> targeting machine architectures. The following is a simplification, but 
> it gives the gist of it.
> 
> 1. The compiler builds Ada source text into an intermediary code, called 
> 'PXC' (a kind of abbreviation for 'extended pseudo-code'). These PXC 
> files are distributed to the target machines. Each PXC file is a module, 
> and a complete program comprises many such modules (perhaps hundreds of 
> them, or even thousands).
> 
> 2. Each target machine itself has a program called the Realizor, which 
> generates a real executable file, comprising actual machine code for the 
> architecture of its own processor(s), from the complete set of PXC 
> modules that go to make up the program.
> 
> One of the big advantages of doing it this way is that global 
> optimisations, including inlining of cross-module calls, can be 
> performed by the Realizor. In addition, the Realizor can implement a 
> strategy of capturing profiling data (execution statistics) for the 
> program, and periodically re-realising it to yield still better 
> optimisations.
> 
> 3. Because of the way the Realizor works, all privilege level-changing 
> calls (e.g. into the kernel) can be removed. Security is, nevertheless, 
> fully maintained.
> 
> (I also intend the technology to remove all use of hardware paging; this 
> will be replaced by a more intelligent software-based segment-swapping 
> mechanism.)
> 
> 4. Because of 3 above, it is possible for the kernel and all the device 
> drivers and other low-level software to be PXC modules, mixed in by the 
> Realizor along with all the other PXC modules. This means that many 
> kernel calls can be inlined, effectively eliminating all call overhead 
> on them.
> 
> I believe these technologies would enable a dedicated piece of software, 
> running 24/7, to run significantly faster.
> 
> When you consider how important performance is on today's vast farms of 
> servers, that could be a pretty compelling reason for people to switch 
> from traditional operating systems.
> 
> All I have to do is to do it :-)
> 
> 
> 
> I'm hoping it could be a way of getting Ada back into the mainstream. We 
> all know in this forum that building future software in Ada, especially 
> server software, would be a big step towards making it more secure and 
> reliable.
> 
> PS: There's a lot more about this scheme that I would like to say, but I 
> don't want to turn this post into a dissertation, and I do want to get 
> to bed soon. If you have any burning questions, please ask.

Why can't LLVM be your PXC?  LLVM already is your PXC and already built out your Realizors for a plethora of ISAs.

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

[Nick Roberts]

On 07/04/2019 05:32, Optikos wrote:

> Why can't LLVM be your PXC?  LLVM already is your PXC and already built out your Realizors for a plethora of ISAs.

It is a very good idea, and I'll look into it.

However, I should point out that there are a few fundamental differences 
in what LLVM supports and what PXC would need to do. What I think I 
would need to do is to make some adaptations to LLVM to be able to use 
it. I suspect I'd need to make a fork. But it might be possible.

Many thanks

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

[Optikos]

On Sunday, April 7, 2019 at 6:35:39 AM UTC-4, Nick Roberts wrote:
> On 07/04/2019 05:32, Optikos wrote:
> 
> > Why can't LLVM be your PXC?  LLVM already is your PXC and already built out your Realizors for a plethora of ISAs.
> 
> It is a very good idea, and I'll look into it.
> 
> However, I should point out that there are a few fundamental differences 
> in what LLVM supports and what PXC would need to do. What I think I 
> would need to do is to make some adaptations to LLVM to be able to use 
> it. I suspect I'd need to make a fork. But it might be possible.
> 
> Many thanks

You might be correct that LLVM as it stands ill serves Ada regarding a few microfeatures of Ada that have not yet appeared in the other LLVM-based languages (e.g., Clang, Flang).  This was certainly true of C/C++'s GIMPLE in GCC when GNAT's upper Ada-semantics layer was bolted onto C-/C++-centric GIMPLE by Richard Stallman & Robert Dewar via the tree transducer around 1994.  Although they initially thought that they found 11 gaps in GIMPLE that Ada needed, in the end they found that there existed a half dozen or so microfeatures of Ada that were not already microfeatures of C/C++ down deep.  You (or Shark8 in his new Ada compiler named Byron) might find a similar quantity of new territory for LLVM for which Ada is an unforeseen stressor on LLVM's assumptions and on LLVM's current scope-of-work.

Part of me thinks that you are biting off more than you can chew.  But there is another part of me that says, “Well, I would have likewise said exactly the same thing about Linus Torvalds rewriting Minix at the start of his life's-work project, so who am I to rain on someone else's parade?”  I admire your initiative and drive.  Please go forth & prosper on all that it takes to make your vision reality; the future of Ada needs you to succeed.

Speaking of Shark8's Byron, you might want to take a look at it.  Edward has been looking for more contributors to Byron.  Perhaps you could join forces together.  (With these hints about perhaps using LLVM and Byron, you might be further toward your goal than you currently think, when compared to starting from scratch.  Just food for thought & creativity.)
https://github.com/OneWingedShark/Byron