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?
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.
Jon S Anthony
In article <4s8rud$9j3@tribune> Mark McKinney <mck...@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
David Wheeler
Mark McKinney (mck...@mail.concentric.net) wrote:
: It has been claimed that the capability to interface with other languages
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: whe...@ida.org
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_ <eic...@cygnus.com>
Cygnus Support, Eastern USA
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.
Robert C. Leif, Ph.D.
The following appeared on Comp.Lang.Ada
----------------------------------------------------------------------------
-------------
Date: Mon, 15 Jul 1996 02:12:25 GMT
From: Nasser Abbasi <nas...@APLDBIO.COM>
Subject: Re: Why couldn't an operating system be written in ada
>From: Mark McKinney <mck...@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
Brian Rogoff
j...@organon.com (Jon S Anthony) writes:
In article <4s8rud$9j3@tribune> Mark McKinney <mck...@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
Nasser Abbasi
From: Mark McKinney <mck...@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: nas...@apldbio.com
MSEE(control), MSCS, MSCE, FM (Fide Chess Master).
Jon S Anthony
> > 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...)
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: ola...@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)
---------------------------------------------------------------------------
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.
Hannes Haug
>>>>> "Robert" == Robert Dewar <de...@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
wfranck
wfranck
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
Marin David Condic, 407.796.8997, M/S 731-93
Robert Dewar <de...@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.
>
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: COND...@PWFL.COM
West Palm Beach, FL 33410-9600 Internet: CON...@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."
===============================================================================
Michael Feldman
In article <4shjeg$5...@herald.concentric.net>,
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
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:denn...@escmail.orl.mmc.com |
| Home - mailto:denn...@iag.net |
| URL - http://www.iag.net/~dennison |
Larry Kilgallen
In article <31F37B86...@escmail.orl.mmc.com>, "Theodore E. Dennison" <denn...@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
Felicia R. Rosemond (214)-462-5371 ple1 SE
dsfkjfdfgvlkjdfb
Greg Harvey
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".
Kent Mitchell
Greg Harvey (gha...@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!
Wallace E. Owen
In article <31F3E61E...@dseg.ti.com>,
Felicia R. Rosemond (214)-462-5371 ple1 SE <fel...@dseg.ti.com> wrote:
>dsfkjfdfgvlkjdfb
I see your point.
// Wally
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.
Bob Kitzberger
Pascal Martin @lone (pma...@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 r...@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html
Pascal Martin @lone
In article <4tr8op$f...@rational.rational.com>, rlk@pelton (Bob Kitzberger) writes:
>Pascal Martin @lone (pma...@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.
cenc...@gmail.com
> 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?
Lucretia
George Shapovalov
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..
russ lyttle
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.
Rabican
> 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?
Rmox from university kent in Uk loosk awesome
can ada do CSP?
Niklas Holsti
> 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?
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
. @ .
Dmitry A. Kazakov
> 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.
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
lyttlec
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.)
lyttlec
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.
russ lyttle
> On Tue, 26 Feb 2019 18:32:12 -0500, lyttlec <lyt...@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.
>
> 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.
Dmitry A. Kazakov
> 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.
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.
Dmitry A. Kazakov
> That is all true. You could make the case that C turns your computer
> into a PDP-11. I was being generous.
MOV -(PC),-(PC)
in C, if I correctly remember the famous PDP-11 one-liner.
Patrick Jakubowski
russ lyttle
> 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.
>
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.
russ lyttle
digging, but it looks to me like gnat depends on a POSIX layer.
Is that true?
Niklas Holsti
> 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
> Thus my desire for an OS and Ada not dependent on any POSIX layer.
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?
systems don't have any POSIX layer.
Dmitry A. Kazakov
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
Dmitry A. Kazakov
> 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?
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.
russ lyttle
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.
russ lyttle
> 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.
>
Dmitry A. Kazakov
Shark8
russ lyttle
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?
Niklas Holsti
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.
Randy Brukardt
news:q56bt3$kbn$1...@gioia.aioe.org...
...
> 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).
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.
G. B.
> I am curious myself if I could prepare and provoke ADA to keep data
> structures in L1 cache.
>
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.
Simon Wright
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
fabien....@gmail.com
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.
>
Optikos
>
> > liability. Besides the OS could perform most of work that the language
> > runtime does. So why not build an OS in ADA?
>
> 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.
russ lyttle
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.
Norman Worth
> 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.
Norman Worth
at AT&T to write UNIX for that machine, long before VMS.
Nick Roberts
> Em sábado, 13 de julho de 1996 04:00:00 UTC-3, Mark McKinney escreveu:
>> 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?
>
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.
Optikos
Nick Roberts
> Why can't LLVM be your PXC? LLVM already is your PXC and already built out your Realizors for a plethora of ISAs.
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
Optikos
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