Green Hiils AdaMULTI 2000 -> Motorola Coldfire

Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Mark Fisher]

I am currently getting to grips with the Green Hills `AdaMULTI`
compiler/environment
using the Coldfire MCF5307 processor.

In the coming weeks I am doing some risk reduction which is
being ported from XDAda (83) / Motorola 68020.

Any tips for a new AdaMULTI user? In particular are there known
weaknesses/problems
that I should steer clear of?

Many thanks

Mark

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Martin Dowie]

Mark,

I don't know if the problems are still current, but here is a snippet
from a conversion report to GH AdaMULTI (but targetted at PPC):

"The first problem we hit was where the ADA'83 code used types with
16 bit representation clauses to access 16 bit off board registers. In
ADA'83 reading and writing to variables of these types compiled to
a single access and the code worked fine. In GH ADA'95, however,
the code was compiled into two byte accesses. This often had the effect
of generating a bus error as some of the addresses in question cannot
physically be accessed as 8 bits."

Some may argue that it was sloppy for the original code not have some
embedded assembler to do the read/writing anyway, but that's not really
the point here. I suspect that many projects don't go to this length if an
"all Ada" version works.

Also, if you are using AdaMULTI 1.8.9b (or lower?) then I understand
interrupt 18 is reserved. That's an old version now though so you should
be ok if using 2.0.x up.



Mark Fisher <MAFisher@ukgateway.net> wrote in message
news:93igkj$grt$1@lure.pipex.net...
> I am currently getting to grips with the Green Hills `AdaMULTI`
> compiler/environment
> using the Coldfire MCF5307 processor.
>
> In the coming weeks I am doing some risk reduction which is
> being ported from XDAda (83) / Motorola 68020.
>
> Any tips for a new AdaMULTI user? In particular are there known
> weaknesses/problems
> that I should steer clear of?
>
> Many thanks
>
> Mark
>
>
>

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Tucker Taft]

Martin Dowie wrote:
> 
> Mark,
> 
> I don't know if the problems are still current, but here is a snippet
> from a conversion report to GH AdaMULTI (but targetted at PPC):
> 
> "The first problem we hit was where the ADA'83 code used types with
> 16 bit representation clauses to access 16 bit off board registers. In
> ADA'83 reading and writing to variables of these types compiled to
> a single access and the code worked fine. In GH ADA'95, however,
> the code was compiled into two byte accesses. This often had the effect
> of generating a bus error as some of the addresses in question cannot
> physically be accessed as 8 bits."
> 
> Some may argue that it was sloppy for the original code not have some
> embedded assembler to do the read/writing anyway, but that's not really
> the point here. I suspect that many projects don't go to this length if an
> "all Ada" version works.

pragma Atomic would presumably solve this problem in Ada 95.


-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom, Inc. (A Titan Company) Burlington, MA  USA
(AverCom was formed 1/1/01 from the Commercial Division of AverStar)
(http://www.averstar.com/services/ebusiness_applications.html)

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Martin Dowie]

I don't have access to the new code - but the same report then gives
an example of what they did do (at the time) to workaround this. They
may have changed this again since then of course...

Do you really want to see it?.. I've put it 'off screen' to protect young
children

If you're at all skeamish them turn away now!..

Tucker Taft <stt@averstar.com> wrote in message
news:3A5DBD1E.D4C4C5F7@averstar.com...
> pragma Atomic would presumably solve this problem in Ada 95.


|
|
v


|
|
v

with System.Storage_Elements;
with Unchecked_Conversion;

procedure test is

  type Rec_Type is
    record
      a : INTEGER range 0..255 := 0;
      b : BOOLEAN := FALSE ;
      c : BOOLEAN := FALSE ;
      d : BOOLEAN ;
      e : BOOLEAN ;
      f : BOOLEAN ;
      g : BOOLEAN ;
      h : BOOLEAN ;
      i : BOOLEAN ;
    end record;

  for Rec use record
      a at 0 range  0.. 7;
      b at 0 range  8.. 8;
      c at 0 range  9.. 9;
      d at 0 range 10..10;
      e at 0 range 11..11;
      f  at 0 range 12..12;
      g at 0 range 13..13;
      h at 0 range 14..14;
      i at 0 range 15..15;
    end record;

  pragma Volatile (Rec);

  Rec_Copy : array (0 .. 2) of Rec ;

  Rec_Copy_Int : array (0..2) of Short_Integer;
  for Rec_Copy_Int use at System.Storage_Elements.To_Address
(16#0009_FF3C#);

  function Rec_To_Short is new Unchecked_Conversion (Rec, Short_Integer);

begin
   Rec_Copy (1).e := FALSE;
   Rec_Copy_Int (1) := Rec_To_Short (Rec_Copy (1));
end;

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Larry Kilgallen]

In article <3a5dc033$1@pull.gecm.com>, "Martin Dowie" <martin.dowie@gecm.com> writes:

> Do you really want to see it?.. I've put it 'off screen' to protect young
> children

And what makes you think young children have a screen height less than
mine (44 lines) ?

:-)

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Brian Courtney]

We recently ported a 200,000+ sloc app (MIPS) from Ada83 (Aonix)
to GHS Ada95 as part of an evaluation of the AdaMULTI2000
environment.  The only problem we experienced was not
with the compiler/environment, rather some bad assumptions
made by the original developers about the size of subtypes.
NOTE: The language does not require objects of a subtype to
be the same size as objects of the parent type.  As you
might expect, the two compilers implemented this differently.
The Aonix Ada83 compiler would preserve the size of subtypes
from the parent type and the GHS Ada95 compiler would not (it
seemed to chose the smallest size possible based on the range
of the subtype).  Either implementation is allowed by the language.

A misunderstanding by the developers, or an oversight in the
language? Either way, this issue has plagued more than one
project, so it may be something you want to be on the lookout for.
I've used XDAda in the past, but can't recall its behavior.  In any
event, the moral of the story is "don't assume the size of a subtype".

Hope this helps,

Brian Courtney

Mark Fisher wrote:

> I am currently getting to grips with the Green Hills `AdaMULTI`
> compiler/environment
> using the Coldfire MCF5307 processor.
>
> In the coming weeks I am doing some risk reduction which is
> being ported from XDAda (83) / Motorola 68020.
>
> Any tips for a new AdaMULTI user? In particular are there known
> weaknesses/problems
> that I should steer clear of?
>
> Many thanks
>
> Mark

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Robert Dewar]

In article <3A5DC6D5.5A8446D8@hercii.mar.lmco.com>,
  Brian Courtney <bcourtn@hercii.mar.lmco.com> wrote:

> A misunderstanding by the developers, or an oversight in the
> language? Either way, this issue has plagued more than one
> project, so it may be something you want to be on the lookout
> for.

We decided early on in the GNAT project that we would always
make the object size of subtypes the same as the parent size.
Otherwise the incompatibilities with Ada 83 in practice get
very fierce. The SIZE design in Ada 95 is flawed, in that it
simply did not very well understand the purpose or typical
usage of this attribute and the typical behavior of Ada 83
compilers.

Yes, in a formal sense, Ada 95 just chose one possible
semantics for sizes that was formally permitted by Ada 83,
but the only trouble was that the choice was different from
all commonly used Ada 83 compilers.

In GNAT, we do make sure that the allocation of objects is
typically the same as Ada 83 compilers, and we also provide
the Object_Size attribute to override this assumption on a
subtype specific basis if necessary.

However, we are bound by the (unfortunate) rules on the 'Size
attribute, which for example require that Natural'Size be 31,
when nearly all (all in common use?) Ada 83 compilers gave
32 for Natural'Size.

In GNAT, we also provide the 'VADS_Size attribute that gives
the same value for the Size attribute that VADS would have
given, and even more radical, the Use_VADS_Size pragma which
causes *all* size attribute to be treated as VADS_Size. Pretty
ugly, but in extreme cases of difficulty in porting old code
covered with assumptions about SIZE, useful :-)


Sent via Deja.com
http://www.deja.com/

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Marc A. Criley]

One other aspect regarding 'Size, types, and subtypes.  This one bit us
when porting from Alsys Ada 83 to GNAT.

If a type has a 'Size clause applied to it, specifying a size larger
than what is actually required, and a subtype off that type is defined,
the subtype does _not_ inherit the parent's size specification.  For
example:

   type Counts is range 0..128;
   for Counts'size use 32;

   subtype Subcounts is Counts range 1..128;

then
   Counts'Size is 32
   Subcounts'Size is 8

This is caused by a gap in the Ada 95 definition regarding "sizes",
which I think Robert Dewar alluded to in an earlier message.  I don't
recall the LRM reference that results in this behavior, but it's
defininely there and one is barred from making the behavior otherwise.

I recall, though, ACT informing me that _objects_ of either of those
Counts or Subcounts types would occupy the requested 32 bits (and they
do in GNAT)--I believe there was some implementation freedom regarding
that aspect.

In the few places where we had to deal with this situation, we simply
replaced the subtype with the parent type at, and only at, the place
where the difference in size had an effect.  Everywhere else we
continued to use the subtype to ensure proper type constraining.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com




Brian Courtney wrote:
> 
> We recently ported a 200,000+ sloc app (MIPS) from Ada83 (Aonix)
> to GHS Ada95 as part of an evaluation of the AdaMULTI2000
> environment.  The only problem we experienced was not
> with the compiler/environment, rather some bad assumptions
> made by the original developers about the size of subtypes.
> NOTE: The language does not require objects of a subtype to
> be the same size as objects of the parent type.  As you
> might expect, the two compilers implemented this differently.
> The Aonix Ada83 compiler would preserve the size of subtypes
> from the parent type and the GHS Ada95 compiler would not (it
> seemed to chose the smallest size possible based on the range
> of the subtype).  Either implementation is allowed by the language.
> 
> A misunderstanding by the developers, or an oversight in the
> language? Either way, this issue has plagued more than one
> project, so it may be something you want to be on the lookout for.
> I've used XDAda in the past, but can't recall its behavior.  In any
> event, the moral of the story is "don't assume the size of a subtype".
> 
> Hope this helps,
> 
> Brian Courtney

Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Robert Dewar]

In article <3A5EF610.66C153D2@earthlink.net>,
  "Marc A. Criley" <mcquad2@earthlink.net> wrote:
>  For
> example:
>
>    type Counts is range 0..128;
>    for Counts'size use 32;
>
>    subtype Subcounts is Counts range 1..128;
>
> then
>    Counts'Size is 32
>    Subcounts'Size is 8
>
> This is caused by a gap in the Ada 95 definition regarding
> "sizes", which I think Robert Dewar alluded to in an earlier
> message.

This is NOT a "gap" in Ada 95. The above behavior is
specifically required by the Ada 95 RM, and any Ada 95
compiler that supports annex C that does NOT give this behavior
is (rather seriously) non-conforming. The relevant RM section
is 13.3

   55  The Size (if not specified) of a static discrete or
       fixed point subtype should be the number of bits needed
       to represent each value belonging to the subtype using
       an unbiased representation, leaving space for a sign bit
       only if the subtype contains negative values.  If such a
       subtype is a first subtype, then an implementation
       should support a specified Size for it that reflects
       this representation.

Clearly this requires a size of 8 for the above subtype.
Remember that recommendations of this kind become requirements
if annex C is supported.

> I don't recall the LRM reference that results in this
> behavior, but it's defininely there and one is barred from
> making the behavior otherwise.

Yes, right, but that's not a "gap", it is well defined
requirement. If anything it is Ada 83 that has the gap in
leaving this unspecified (i.e. Ada 83 is equivalent to Ada 95
without the advice and without Annex C). The trouble is that
the designers simply made a choice which was pragmatically
wrong, since it did not match what almost all commonly used
Ada 83 compilers did (I have been told, but do not know first
hand that the Intermetrics compiler for IBM mainframes made
the choice in the Ada 95 style, which if true, probably
accounts for the mistake).

It is an unfortunate mistake, since it is the source of a
significant amount of porting problems.

Making the situation worse, the Size attribute in Ada 95 is
subtype specific. You might think that this means that you
can specify it for subtypes, but no such luck (this was an
intended feature, but (unwisely in my view) got removed rather
late on). So compounding the design mistake here is that no
only is the default size wrong in the above example, but you
cannot override this incorrect size.

In GNAT, we have added the Value_Size attribute, which can
be specified for subtypes, so you could do:

  for Subcounts'Value_Size use 8;

and then the value of Subcounts'Size would be 8 (yes, it would
be neater if we could say:

  for Subcounts'Size use 8;

but there is a rule in the RM prohibiting this extension. They
are definitely out to make this as annoying as possible :-) :-)

> I recall, though, ACT informing me that _objects_ of either
> of those Counts or Subcounts types would occupy the requested
> 32 bits (and they do in GNAT)--I believe there was some
> implementation freedom regarding that aspect.

Yes, there is implementation freedom here, and the decision
in GNAT is to always inherit what we call the Object_Size
from the parent type, since we found that was a very common
assumption in legacy code. Furthermore, Object_Size is
introduced as an attribute in GNAT so that you can control
the object size (on a subtype by subtype basis).

So as long as you are using GNAT, there are relatively easy
ways of dealing with this. And if putting in a bunch of
declarations is still too much, we have the:

   pragma Use_VADS_Size;

configuration pragma, which duplicates (as closely as possible,
the documentation is not entirely complete), the effect of both
the size attribute and the size attribute definition clause in
VADS Ada 83.

> In the few places where we had to deal with this situation,
> we simply replaced the subtype with the parent type at, and
> only at, the place where the difference in size had an
> effect.  Everywhere else we continued to use the subtype to
> ensure proper type constraining.

Of course finding these places can be tricky. A particularly
nasty case is the following:

  type x is record
     A : Natural;
     B : Natural;
  end record;

  for x use record
    A at 0 range 0 .. Natural'Size - 1;
    B at 0 range Natural'Size .. 2 * Natural'Size - 1;
  end record;

  for x'size use 2 * Natural'Size;

The horrible thing about this declaration is that in almost
all Ada 83 compilers it nicely lays out (assume 32 bit integer)
the record as two 32-bit words, with a length of 64.

In Ada 95, it silently lays out the record with the fields
occupying 31 bits, the second field overlaps word boundaries,
and the record has a size of 62 bits, likely leading to
entirely horrible inefficiencies.

Indeed a suggestion we have filed is to always generate a
warning for Natural'Size on the grounds that it is almost
certainly a nasty surprise of this type :-(


Sent via Deja.com
http://www.deja.com/