ROGERS@uhcl.CSNET ("Pat Rogers, High Tech Lab") (10/20/87)
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