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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc65fe38e6751a89 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Aeonix Ada 95 Date: 1997/03/10 Message-ID: X-Deja-AN: 224407806 References: <857938743.26136@dejanews.com> <33237061.6A5D@bix.com> <33239BEA.21C9@aonix.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-03-10T00:00:00+00:00 List-Id: Dave Wood wrote <> Well I don't think there is any conflict of interest here, except in the normal sense of competition! But anyway, I certainly don't want to create incorrect impressions, so let me say exactly what I was talking about. First, there is no such think as "validating the real-time annex", at least not with version 2.0.1 of the ACVC. There is only one overall validation status, and for anything else you have to study the results in detail. The validation simply reports which tests pass, which tests fail, and which tests are inapplicable. There are three reasons for tests being inapplicable: 1. The test is plain wrong in a particular environment. For instance, in one of our upcoming validations, on a cross-target with no I/O, three tests expect Name_Error to be raised when opening a non-existent file, when clearly Use_Error is allowed by the RM. The (perfectly reasonable) resolution here was that these tests should be considered as passing in this environment if Use_Error is raised, since the RM specifically allows for the raising of Use_Error in such a case. 2. The tests is testing for some implementation variation that is not relevant to the current implementation. For example, there are a whole lot of IO tests that carefully insist that *if* you have, as allowed, a very small limit on the range of Count, then you properly raise various exceptions. But in practice most implementations make Count derived from Integer, so these tests are inapplicable and that is a good thing! 3. The test is ruled inapplicable for a given validation as a result of an appeal to RM 1.1.3(6): 6 Contain no variations except those explicitly permitted by this International Standard, or those that are impossible or impractical to avoid given the implementation's execution environment; The impossible or impractical phrase is of course a subjective standard, that is potentially tricky to judge. Two examples from current reported validations are: The AONIX compiler for NT only implements 7 levels of priorites because there are only 7 levels of task priorities provided in NT, so if you are maping priority levels one-to-one, the requirement of 31 levels of priority cannot be met. The Greenhills compiler for VxWorks does not pass the Annex D tests that test for strict conformance with the dispatching model of annex D. That is because VxWorks has subtly "wrong" semantics from the point of view of annex D. Actually I am not quite sure about the Greenhills case, I think these tests may be considered not supported, rather than inapplicable. The line between these two categories is a delicate one, so best to look at the actual test reports in the VSR's to determine exactly which tests pass and which do not. As far as other compilers go, I have not looked carefully at the validation profile of the embedded x86 product from Aonix. It lists two inapplicable tests, but I do not know if these are 1.1.3(6) cases or not, if not, then my statement is certainly not correct with respect to this validation, and I apologize for the mistake. The validated compilers list changes all the time (a good thing!) so any statement about its state is likely to become false with the march of time. When I said that GNAT passed the real time annex I meant that it did so without appealing to RM 1.1.3(6). Our position is to provide at least a mode in which annex D requirements are met completely. In the case where there is a clash between the underlying OS thread semantics and the requirements of annex D, we provide a choice between following annex D exactly, or just taking whatever you get from the underlying threads. Now one EXTREMELY IMPORTANT point is that it is perfectly possible to use a compiler with deviations from the standard. This is PARTICULARLY true in the case of annex D, since relatively few applications will depend on the details of the annex D semantics. After all in Ada 83, all such details were implementation defined, and yet many applications successfully used tasking (of course many applications also avoided the use of tasking because of the lack of definition, and we hope that the deterministic semantics of annex D will bring some of these applications back into the tasking fold :-) For example, the Greenhills compiler is the only off-the-shelf VxWorks compiler today (although perhaps that statement too will be obsoleted soon). Many Vxworks users would actually prefer that their Ada compiler follow the VxWorks semantics, and indeed as a default dispatching policy, this is reasonable, but you cannot expect to get accurate FIFO_WITHIN_PRIORITIES behavior in this environment (and indeed the compiler should reject the attempt). Dave Wood will remember that I was one of the people who most vociferously argued that the inability on NT to support 31 levels of priority should not be considered too negatively, since for many applications you WANT the 1-1 mapping, and you can't have both 31 levels of priority and this 1-1 mapping (complaints to Microsoft, not here!) However, I was not arguing that 7 = 31! If you have an application (RMA scheduling is a typical case which results in such a requirement) that requires 31 levels of priority then you will be out of luck, and your perfectly valid Ada 95 program will not run. Now I would assume that the embedded version of the compiler does not have this limitation of 7 priority levels, so very probably it does NOT have to rely on 1.1.3(6), and thus in thesense I was talking about DOES fully support Annex D on a general purpose platform. As I said, my validation knowledge was a little out of date (a state which I certainly hope will frequently be the case as new targets are validated!) The lesson to be learned from this discussion is that everyone seriously using a compiler should study the validation results in detail. Especially where there are 1.1.3(6) variations claiming variations not explicitly permitted by the RM, other than by virtue of this clause, it is important for users to understand the limitations. In some cases, these limitations can cause programs to silently malfunction even though they are 100% correct Ada 95. For example, if you have two tasks A and B, where A has priority Priority'First + 6 and B has priority Priority'Last - 6, then Ada semantics says that task B has a greater priority than A, but in an environment with only 7 levels of priority, the priorities will be silently reversed. This is a constructed example, and in the particular case of 7 levels of priority, it seems pretty unlikely that this would arise. However 1.1.3(6) has no language about the resulting variations being detected easily, or being unlikely to cause trouble, so it is definitely a buyer beware situation here. Going back to the GNAT validations. Ada Core Technologies has made a policy decision that we will only do validations in which we fully support the language (no unsupported tests in the VSR), and where inapplicable tests never appeal to 1.1.3(6), i.e. the only reasons for tests being inapplicable are cases 1 and 2 described above. We accomplish this goal by two methods: 1. If we cannot validate under these conditions in a given environment, we simply don't validate. Now of course commercial pressures might cause us to change this viewpoint (money talks!) but so far we have not had to relax this position. 2. Where there is a clash between the underlying threads model of the operating system, we provide a choice of threads models, the user either has the choice of using the OS thread model, with its limitations, or of using our own thread model which is exactly annex D compliant. We prefer that the threads model provided by the OS be exactly right, and for cases where we have some technical interaction (SGI, RTEMS, Tenon Machten), this can be achieved. But in other cases (notably Solaris), we need to offer the choice of threads models. The choice of the annex D thread model is made either automaticaly if a pragma is used indicating the requirement, or as a result of a compiler option. We certainly are NOT saying that compilers that appeal to 1.1.3(6) are in any sense unusable. As I mentioned earlier, I was one of the really strenuous arguers that the NT limitation I discussed above is one that should be allowed under 1.1.3(6), even though it is perfectly possible to provide exact annex D semantics on NT. In fact I think I can fairly say that without my arguments on behalf of the Aonix petition in this matter, the decision might easily have been made the other way! It is often the case that a compiler is fully usable even if it implements NONE of the real time (or any other) annex, in a particular situation. So certainly any implication that a compiler is unusable just because there is a single feature unsupported is total nonsense. However, here at Ada Core Technologies, we think it makes things simpler for users if they can get an ACT validated compiler and know that they do not have to worry about 1.1.3(6) issues, and that if something is required to be supported in the RM (as opposed to being explicitly optional, or implementation advice), then they can count on the fact that there are no intentional 1.1.3(6) deviations. Dave, what would be useful, and would help clear up any confusion I may have caused, is for you to quickly summarize the details of the inapplicable tests in the embedded validation. For the record, the inapplicable tests in the GNAT annex D validations correspond to the non-implementation of the asynchronous task capability. This capability was explicitly made optional in the RM, recognizing that it is unlikely to make sense in other than bare target environments. Robert Dewar Ada Core Technologies