Re: Support of Task Interrupt Entries

[eachus@spectre.mitre.org (Robert I. Eachus)]

   >   The standard can't reasonably define a set of addresses and
   >interrupts to support, so that is left to the implementors, who can
   >choose none.  Of course, the rules of J.7.1 do apply to any interrupt
   >entries that are supported.

In article <1998Oct13.183104.3784@nosc.mil> claveman@inetworld.net (Charles H. Sampson) writes:

  >    Actually, it looks to me like the second sentence of C.3.2(22) 
  > blesses this compiler's implementation.  It says, "This function 
  > [Ada.Interrupts.Reference] raises Program_Error if attaching task 
  > entries to interrupts ... is not supported."

  >     I thought I had read the pertinent sections of the LRM quite 
  > closely.  I even searched around a bit to see if "permitted" had been 
  > given a specialized, non-standard, meaning.  Now, on rereading those 
  > sections, I see that I missed a crucial point.  1.1.3(16) says that a 
  > standard-conforming implementation must support each capability 
  > _required_ by the core language.  Since J.7.1(1) says, "Implementations 
  > _are permitted_ ...," this is obviously not a requirement.  All very 
  > clear, once you see it.  Duh!

   This is one of those cases where the RM goes as far as it can, and
the marketplace has to take it the rest of the way.  The RM can't
require that the hardware has any particular set of interrupts, but it
does require for the SP and RT annexes that the package Ada.Interrupts
be present.  Annex J is always required, but since support for
interrupt entries was not required in Ada 83, they are permitted, not
required by the various annexes.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...