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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c30642befcd7bf85
X-Google-Attributes: gid103376,public
From: Ken Garlington <GarlingtonKE@lmtas.lmco.com>
Subject: Re: New GNAT ports (was Re: Ada and Automotive Industry)
Date: 1997/01/09
Message-ID: <32D534D0.7074@lmtas.lmco.com>#1/1
X-Deja-AN: 208761855
references: <dewar.851455793@merv> <5asvku$jtu$1@goanna.cs.rmit.edu.au>
 <32D2B847.6A7@lmtas.lmco.com> <5avfqo$it9$1@goanna.cs.rmit.edu.au>
content-type: text/plain; charset=us-ascii
organization: Lockheed Martin Tactical Aircraft Systems
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.01 (Win95; U)
Date: 1997-01-09T00:00:00+00:00
List-Id: <comp.lang.ada>


Richard A. O'Keefe wrote:
> 
> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> >Couldn't this be handled via a combination of existing Ada support
> >(address clauses, etc.) plus linker support?
> >I don't know if you want to specify origins for
> >random code; usually, it's for a logically related set of
> >code/data/literals, or for a specific object.
> 
> The only reason that I bothered about the placement of code at all
> was that the 8051 book I was studying included a memory test program
> that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
> supply address clauses for code.

As Dr. Dewar has already responded, you can (and we have) done this in
Ada 83.
In general, ROM tests can be done in Ada 83 (and in Ada 95, with the
ability
to manipulate addresses, it can be done _portably_ ;) Usually, rather
than attempting to place the Ada objects to be tested at certain areas,
we perform
address manipulations to scan a given area of memory, where the regions
are
specified as constants not related to the placement of Ada objects.

_RAM_ tests, on the other hand, are a little interesting in Ada (and a
lot
of other high-order languages). Consider, for example, a non-destructive
RAM
test involving writing a value to RAM, reading the value back, and
making sure
they match. A typical algorithm is to break RAM into blocks of a
particular size,
reserve one block for the RAM test, and then do the following:

  Test(Reserved_Block);
  for Block_Index in All_Blocks loop
    Reserved_Block := RAM_Block(Block_Index);
    Test(RAM_Block(Block_Index));
    RAM_Block(Block_Index) := Reserved_Block;
  end loop;

What gets interesting is that the stack and heap are going to be
destroyed as a part
of this procedure. If Test tries to access the stack/heap while it's
overwritten...
bad business! Perhaps

   pragma (Local_Values_in_Registers_Only)

would help? :)

Usually, we write such a routine in assembly. Since it's such a small
part of the
total system, the maintenance impacts are negligible.

> I suggested a pragma because it seemed
> to me that they were the _right_ way to add things like that; that
> specific pragma wouldn't change the meaning of the code, so could be
> stripped out for testing elsewhere.  When you are trying to make a
> case that "language X can solve problem Y", opponents sometimes
> regard appeal to "linker support" as a copout.

Realistically, however, there are always some low-level operations
that will require linker support, regardless of the language, for any
language which allows the compilation of components at different times.
So, I would say that someone who makes such an objection isn't going to
be swayed by any reasonable argument.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com