From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!ucbvax!uhcl.CSNET!ROGERS
From: ROGERS@uhcl.CSNET ("Pat Rogers, High Tech Lab")
Newsgroups: comp.lang.ada
Subject: tailoring Ada runtime systems
Message-ID: <8710241723.AA01320@ajpo.sei.cmu.edu>
Date: Tue, 20-Oct-87 12:14:00 EST
Article-I.D.: ajpo.8710241723.AA01320
Posted: Tue Oct 20 12:14:00 1987
Date-Received: Tue, 27-Oct-87 02:51:17 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

In recent (more or less, given Info_Ada status) net mail, Ed Berard
(eberard@ajpo.sei.cmu.edu) poses the following questions, which are 
VERY pertinent to the state of Ada runtime systems to date:

>So we have a number of technical, legal, and ethical questions:
>
>   1. If an Ada software engineer just happens to know what the
>      underlying scheduling algorithm is, should he or she design their
>      Ada software in a manner which takes direct advantage of this
>      knowledge?                  

Only if the application requirements (presumably for realtime performance)
are such that no available, "untailored" implementation is sufficient.
Of course, this is the obvious answer, but read on.

>
>   2. Should an Ada software developer require that an Ada development
>      system vendor supply the scheduling algorithm for tasking, with
>      the intention of using this knowledge in the design and
>      implementation of the Ada software?

Same as above.

>
>   3. How much "tailoring" of an Ada development is to be allowed?
>      Specifically, at what point (or points) do we cross the line
>      between issues which are truly outside of Ada, and issues which
>      are best left to "language lawyers"?
>
>   4. If certain types of tailoring or knowledge of the underlying
>      implementation are to be discouraged, what alternatives are
>      available to the Ada software developers?

An alternative to individual, vendor-dependent tailoring is the Ada Runtime
Environment Working Group's (ARTEWG) Catalog of Interface Features and
Options (CIFO, for short). The CIFO is a collection of "common" (a weasel-word
for "standard") interfaces to the underlying RTE, mostly in the form of
packages, which allow the developer to tailor and request services of the
RTE. For a simple example, dynamic priorities are certainly legal as long
as they don't violate the rules for the basic, static priority scheme found
in the RM. The CIFO has a simple Ada package defining the subprograms
involved in dynamically setting, altering and interrogating a task's
priority. Other subjects include how to get historically fast interrupt
response from interrupt entries, asynchronous entry calls, task suspension
and resumption, and many others. This isn't pie-in-the-sky stuff, either.
The members of ARTEWG have experience in realtime applications, as well as
validated Ada compiler implementation. Some (not all) of the interfaces are
a result of existing implementations, and others at least have been implemented
to prove feasibility. Most involve RTE tailoring, with little or no compiler
modification. 

As to what is "outside the language", in my opinion (not necessarily those
of the ARTEWG members), precious little is outside the realm of
possibility. When you consider that the language is designed to be
extensible, only those things that can't be expressed (in a package, for
example) are outside the language. The trite example is Text_IO, which is
an extension of the basic language. (Don't believe that? Look for a new
reserved word in Text_IO.) Other packages that address such issues as
distribution, fault tolerance, and multiprogramming are legal, appropriate
and necessary. 

>
>   5. Are there published lists of questionable practices relating to
>      the above? Are there any published policies?      

Another ARTEWG document that might help is the ARTEWG Catalog of Runtime
Implementation Dependencies (CRID). This is an exhaustive (complete, not
tiring) examination of the RM, with discussion of each and every area in
which the vendor (and thus, the buyer) has implementation choices.

Concerning policies, I suggest the ARTEWG "White Paper" on Ada runtime
systems.

Hopefully, I've not misrepresented the membership of the ARTEWG, and these
opinions are, of course, my own.

I hope these comments will stir up some interest and discussion in the vital
area of Runtime Environments. Rock throwers may line up as necessary...

Regards,
Pat Rogers
Software Engineering Research Center
progers@ajpo.sei.cmu.edu