Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Jeff Creem]

Darrell Higgins <darrellhiggins@uswest.net> wrote in message
news:382386fe.85782690@news.uswest.net...
> Has anybody dealt (successfully) with a port of ADA83 that contains
> 3-bit arrays of enumerated types into GH ADA95? GreenHills does not
> support 3-bit arrays and we are searching for techniques/solutions to
> achieve this port.
> Our application constrains us to keep the arrays, due to the high LOC
> affected. So how about it...Trash the compiler and look for a new one?
> Be kind in reply - I'm a nervous ADA newbie.


I got bit by this as well..It basically comes down to the fact that they
are meeting the minimum standards of the LRM. I just changed the
code so that it was more portable since it was a very small area of code.

WIth lots of LOC in play you have two choices.

Work with Green Hillsto get it included in the compiler (they have been good
for me in the past with
bugs -- not so good on features like this).


Trash compiler and contact ACT (www.gnat.com) and see if there is a port
available for
your interest.

GNAT has the most complete Ada95 support and better rep specs..

3-bit array porting problem from ADA83 to GreenHills ADA95

[Darrell Higgins]

Has anybody dealt (successfully) with a port of ADA83 that contains
3-bit arrays of enumerated types into GH ADA95? GreenHills does not
support 3-bit arrays and we are searching for techniques/solutions to
achieve this port. 
Our application constrains us to keep the arrays, due to the high LOC
affected. So how about it...Trash the compiler and look for a new one?
Be kind in reply - I'm a nervous ADA newbie.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Robert Dewar]

In article <382386fe.85782690@news.uswest.net>,
  darrellhiggins@uswest.net (Darrell Higgins) wrote:
> Has anybody dealt (successfully) with a port of ADA83 that
> contains 3-bit arrays of enumerated types into GH ADA95?
> GreenHills does not support 3-bit arrays and we are searching
> for techniques/solutions to achieve this port.

The Ada 95 RM (in my opinion) dumbs down the language compared
to Ada 83 in terms of what is required in rep specs. In Ada 83,
you were required to implement anything that could be reasonably
easily implemented at the hardware level.

This was of course vague and lead to differences between
compilers.

But in Ada 95, the decision was

a) to make the requirements clearer

b) to limit them to the intersection of things that can be
done easily on ALL architectures.

This means that the required set of rep clauses is really rather
thin in Ada 95, and many Ada 83 legacy programs will contain
perfectly reasonable rep clauses that are NOT required to be
accepted by Ada 95 compilers.

This is one particular example, on typical architectures, the
RM only requires array packing for 1,2 and 4 bits.

Of course this does not stop a compiler going further than the
minimum, and in GNAT, we implement close packing for all
component sizes up to 63 bits.

If you really want to constrain yourself to what is required
to be implemented in the Ada 95 RM, that really in practice
restricts the language pretty severely compared to typical
Ada 83 implementations. We have certainly found in GNAT that
we needed to do a LOT in terms of adding rep clause capabilities
to this minimum set in order to accomodate not only legacy
code from Ada 83 compilers, but also new code with flexible
data structuring requirements not accomodated by the minimum
guarantees of the Ada 95 RM.

Note that actually an Ada 95 compiler is not *required* to
implement rep clauses at all, since the actual requirements,
thin as they are, are in an optional annex.

That means that in any case you need to specify more than just
Ada 95 if you want to use rep clauses at all. Once you get in
the business of applying additional requirements to compilers
beyond basic conformance with the standard, you may as well
require them to have exactly the capabilities you need in this
area, since you are not writing 100% portable code in any case.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Darrell Higgins]

I'm afraid that GreenHills support on this (non-feature) falls into
the 'not-so-good' category, we contacted them for that reason and they
have no intention of including 3-bit array support.
As our code is extensive and spread over 60+ affected modules we will
not be restructuring it!
Thank you for the reply and recommendation of GNAT - I will follow
that up.

On Fri, 5 Nov 1999 22:01:41 -0500, "Jeff Creem"
<jcreem@atetola.mv.com> wrote:

>
>Darrell Higgins <darrellhiggins@uswest.net> wrote in message
>news:382386fe.85782690@news.uswest.net...
>> Has anybody dealt (successfully) with a port of ADA83 that contains
>> 3-bit arrays of enumerated types into GH ADA95? GreenHills does not
>> support 3-bit arrays and we are searching for techniques/solutions to
>> achieve this port.
>> Our application constrains us to keep the arrays, due to the high LOC
>> affected. So how about it...Trash the compiler and look for a new one?
>> Be kind in reply - I'm a nervous ADA newbie.
>
>
>I got bit by this as well..It basically comes down to the fact that they
>are meeting the minimum standards of the LRM. I just changed the
>code so that it was more portable since it was a very small area of code.
>
>WIth lots of LOC in play you have two choices.
>
>Work with Green Hillsto get it included in the compiler (they have been good
>for me in the past with
>bugs -- not so good on features like this).
>
>
>Trash compiler and contact ACT (www.gnat.com) and see if there is a port
>available for
>your interest.
>
>GNAT has the most complete Ada95 support and better rep specs..
>
>

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Steve Mossom]

I haven't delt with your particular problem, however I have been working on
a project porting some legacy code from XD Ada'83  to GreenHills ADA Multi.
We have had numerous (too many to mention!) problems with the way the
compiler handles representation clauses. It seems, from what I have read,
that the ADA'95 LRM makes 'recommendations' to compiler vendors regarding
their implementation in this area it does not really enforce any rules
(quite rightly as it should not be implementation specific) . GreenHills
response to my problems was good to a point - If the problem was allready
fixed in a later issue of the compiler they would ship that to us. More
recently, for issues which are not allready fixed in a later version, we
have been told 'The LRM does not enforce that'  and been given workarounds
for our problems using 'unchecked conversion' which is not the most
desirable way of doing things.

Darrell Higgins <darrellhiggins@uswest.net> wrote in message
news:382386fe.85782690@news.uswest.net...
> Has anybody dealt (successfully) with a port of ADA83 that contains
> 3-bit arrays of enumerated types into GH ADA95? GreenHills does not
> support 3-bit arrays and we are searching for techniques/solutions to
> achieve this port.
> Our application constrains us to keep the arrays, due to the high LOC
> affected. So how about it...Trash the compiler and look for a new one?
> Be kind in reply - I'm a nervous ADA newbie.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Robert Dewar]

In article <3827e839@pull.gecm.com>,
  "Steve Mossom" <stephen.mossom@gecm.com> wrote:
> It seems, from what I have read,
> that the ADA'95 LRM makes 'recommendations' to compiler
> vendors regarding their implementation in this area it does
> not really enforce any rules
> (quite rightly as it should not be implementation specific) .


This is not correct. The recommendations in chapter 13 become
requirements for a compiler that implements Annex C (Systems
Programming), and the ACVC tests do test these requirements.
You should only use a compiler that is 100% validated for
annex C for this kind of job (where rep clauses will be used).

It is the case that there are lots of things you would like to
work that are not requirements even if annex C is implemented.
The subject of this thread (3-bit packed arrays) is an example.

In GNAT, only a relatively small part of the rep clauses that we
implement are those required by the RM. We go far beyond these
minimum requirements. I suspect most/many/all? other Ada 95
compilers also go beyond the minimal requirements. Part of
acquiring an Ada compiler must be your effort to find out what
is implemented, and whether it will meet your needs.

In the case of GNAT, we were largely driven by old Ada 83
compilers, many of which implemented a very rich set of
representation clauses, and we tried to implement everything
we ran across in old Ada 83 legacy code, so that porting is
as simple as possible.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Ted Dennison]

In article <a_3W3.729$QY4.27907@dfiatx1-snr1.gtei.net>,
  "Gleason" <gleason3@gte.net> wrote:

> runtimes, and the release of the next version of our Ada 95 embedded
> software development environment, AdaMULTI 2000.  This engineering

(sigh). Is there some kind of law that says all software released from
1999-2001 must have a name that ends in "2000"?

I thought marketing people were supposed to be *creative*.

Oh well. It will still have the "phase of the moon" feature, won't it?
If not, I'm switching! :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Gleason]

Green Hills is investigating adding support for odd-size array component
sizes.  Prior to this, we had not seen requests for this feature.  The
reason for not supporting this in the past is that on most of the target
architectures we support, it would result in significantly less efficient
code than power-of-2 sizes.  We are investigating support for this when
specifically requested via a 'Component_Size specification, so that the
"default" packed array implementation will remain time efficient, while
allowing for special component sizes when necessary.

However, other priorities derived from more frequent customer requirements
have our Ada 95 product line improving and growing in other areas.
Improvements and additions include a secure memory-protected runtime for
multi-level safety critical and mission critical applications, bare target
runtimes, and the release of the next version of our Ada 95 embedded
software development environment, AdaMULTI 2000.  This engineering focus has
resulted in significant improvements to the entire graphical user inteface,
advances in the area of remote cross debugging (i.e. advanced
multi-tasking/multi-processor debugging features), additional debugger
connection strategies using serial, ethernet, JTAG, BDM and other unique
interfaces required by our customers, and continued improvements in the area
of optimizations across our entire family of embedded Ada95 compilers and
runtimes.

Jim Gleason
Green Hills Software, Inc.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[David Botton]

It's a Microsoft thing that started in 95

David Botton

Ted Dennison wrote in message <80cag4$5rv$1@nnrp1.deja.com>...
>(sigh). Is there some kind of law that says all software released from
>1999-2001 must have a name that ends in "2000"?

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Robert Dewar]

In article <80dfam$ckm$1@news.gate.net>,
  "David Botton" <David@Botton.com> wrote:
> It's a Microsoft thing that started in 95


Gosh, you mean it was Microsoft that chose the name Ada 95
(not to mention Algol 60, Algol 68, Simula 67 etc etc)

:-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Preben Randhol]

Robert Dewar <robert_dewar@my-deja.com> writes:

| In article <80dfam$ckm$1@news.gate.net>,
|   "David Botton" <David@Botton.com> wrote:
| > It's a Microsoft thing that started in 95
|
| Gosh, you mean it was Microsoft that chose the name Ada 95
| (not to mention Algol 60, Algol 68, Simula 67 etc etc)

Not to forget Fortran 77, 90 and 95 :-)

-- 
Preben Randhol                 Affliction is enamoured of thy parts, 
[randhol@pvv.org]              And thou art wedded to calamity. 
[http://www.pvv.org/~randhol/]                    -- W. Shakespeare 

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Darrell Higgins]

To follow up on the 3-bit array problem with Green Hills ADA, Mr.
Miexner from GH contacted our company to say that activity on this
thread has spurred them to reevaluate the odd size array support for
the compiler. They believe an update will be available within 30 days
- which would coincide nicely with our projects design review
milestone! I will post a follow up message upon receipt of the update.
On Sat, 06 Nov 1999 01:51:35 GMT, darrellhiggins@uswest.net (Darrell
Higgins) wrote:

>Has anybody dealt (successfully) with a port of ADA83 that contains
>3-bit arrays of enumerated types into GH ADA95? GreenHills does not
>support 3-bit arrays and we are searching for techniques/solutions to
>achieve this port. 
>Our application constrains us to keep the arrays, due to the high LOC
>affected. So how about it...Trash the compiler and look for a new one?
>Be kind in reply - I'm a nervous ADA newbie.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[David Botton]

Just for pseudo standard proprietary systems.

David Botton
---------------------------
"At Microsoft, we always feel we can improve on a standard" (InsideCOM, p
252)
---------------------------

Robert Dewar wrote in message <80hb9f$qk3$1@nnrp1.deja.com>...
>Gosh, you mean it was Microsoft that chose the name Ada 95
>(not to mention Algol 60, Algol 68, Simula 67 etc etc)
>
>:-)

RE: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Darrell Higgins et al.

Your 3 bit arrays may be applicable to the Human Genome project. They should
be a good way to compress the data. It may also be possible to look for
matching "strings". Would the inclusion of generic characters in
Ada.Strings.Bounded have facilitated your work?

-----Original Message-----
From: Darrell Higgins [mailto:darrellhiggins@uswest.net]
Sent: Thursday, December 02, 1999 6:27 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: 3-bit array porting problem from ADA83 to GreenHills ADA95


On Sat, 06 Nov 1999 01:51:35 GMT, darrellhiggins@uswest.net (Darrell
Higgins) wrote:

>Has anybody dealt (successfully) with a port of ADA83 that contains
>3-bit arrays of enumerated types into GH ADA95? GreenHills does not
>support 3-bit arrays and we are searching for techniques/solutions to
>achieve this port.
>Our application constrains us to keep the arrays, due to the high LOC
>affected. So how about it...Trash the compiler and look for a new one?
>Be kind in reply - I'm a nervous ADA newbie.

A follow up to this thread:

Green Hills provided an update for their compiler that solved our
porting problem. Their response to our need came at a very timely
point in our project, so - Many thanks to Green Hills from Raytheon at
the F-15 Systems Development Center at Luke AFB, Arizona.

Re: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Darrell Higgins]

On Sat, 06 Nov 1999 01:51:35 GMT, darrellhiggins@uswest.net (Darrell
Higgins) wrote:

>Has anybody dealt (successfully) with a port of ADA83 that contains
>3-bit arrays of enumerated types into GH ADA95? GreenHills does not
>support 3-bit arrays and we are searching for techniques/solutions to
>achieve this port. 
>Our application constrains us to keep the arrays, due to the high LOC
>affected. So how about it...Trash the compiler and look for a new one?
>Be kind in reply - I'm a nervous ADA newbie.

A follow up to this thread:

Green Hills provided an update for their compiler that solved our
porting problem. Their response to our need came at a very timely
point in our project, so - Many thanks to Green Hills from Raytheon at
the F-15 Systems Development Center at Luke AFB, Arizona.

Re: 3-bit array ...

[Nick Roberts]

Just out of curiosity ... what is a 3-bit array?

-- 
Nick Roberts
http://www.adapower.com/lab/adaos

RE: 3-bit array porting problem from ADA83 to GreenHills ADA95

[Robert Dewar]

In article <NBBBJNOMKDIAJALCEFIJIEBJDGAA.rleif@rleif.com>,
  comp.lang.ada@ada.eu.org wrote:
> From: Bob Leif
> To: Darrell Higgins et al.
>
> Your 3 bit arrays may be applicable to the Human Genome
> project. They should be a good way to compress the data. It
> may also be possible to look for matching "strings".

This seems unlikely. There is a VERY significant time penalty
for using 3-bit packing instead of 4-bit packing. Unless storage
is VERY tight, and you really don't care about processing time
at all, you do better to specify 4-bit packing which is quite
efficient (since everything can be done with shift and masking
operations).

Usually the only time you want to use odd inefficient component
sizes like this is when you have external data that is formatted
in this manner.

> Would the
> inclusion of generic characters in Ada.Strings.Bounded have
> facilitated your work?

Not clear what this has to do with the subject of 3-bit
packed arrays???


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 3-bit array ...

[Gisle S�lensminde]

In article <3847EF64.EBD41169@callnetuk.com>, Nick Roberts wrote:
>Just out of curiosity ... what is a 3-bit array?
>
>-- 
>Nick Roberts
>http://www.adapower.com/lab/adaos
>
>


-- 
--
Gisle S�lensminde ( gisle@ii.uib.no )   

Re: 3-bit array ...

[Robert A Duff]

Nick Roberts <nickroberts@callnetuk.com> writes:

> Just out of curiosity ... what is a 3-bit array?

People are using that to refer to a packed array of 3-bit components.
For example:

    type T1 is range 1..5;
    type T2 is array(Integer range <>) of T1;
    pragma Pack(T2);

In Ada 95, T1'Size = 3 -- a statement that will no doubt elicit the
usual complaints from Robert Dewar about loose-cannon language design
teams run amok.  ;-) ;-)

Also in Ada 95, T2'Component_Size will be either 3 or 4, depending on
the whim of the compiler writer, which doesn't seem like a good language
design decision.  I'm assuming a 32-bit machine, here.  GNAT has always
supported packing to the 3-bit level.  AverStar's front end, and the
Green Hills compiler that uses AverStar's FE, used to use 4, but now
uses 3, due to customer demand for it.  That's what this whole
discussion has been about.

There's also the issue of whether you can say:

    for T2'Component_Size use 3;

instead of the pragma Pack above.

- Bob

Re: 3-bit array ...

[Tucker Taft]

Robert A Duff wrote:
> 
> Nick Roberts <nickroberts@callnetuk.com> writes:
> 
> > Just out of curiosity ... what is a 3-bit array?
> 
> People are using that to refer to a packed array of 3-bit components.
> For example:
> 
>     type T1 is range 1..5;
>     type T2 is array(Integer range <>) of T1;
>     pragma Pack(T2);
> 
> In Ada 95, T1'Size = 3 -- a statement that will no doubt elicit the
> usual complaints from Robert Dewar about loose-cannon language design
> teams run amok.  ;-) ;-)
> 
> Also in Ada 95, T2'Component_Size will be either 3 or 4, depending on
> the whim of the compiler writer, which doesn't seem like a good language
> design decision.  I'm assuming a 32-bit machine, here.  GNAT has always
> supported packing to the 3-bit level.  AverStar's front end, and the
> Green Hills compiler that uses AverStar's FE, used to use 4, but now
> uses 3, due to customer demand for it. 

Oh dear, I hate to correct Bob on this one, but our front end
still uses 4 given a pragma Pack.  We only use "odd ball" sizes
if the user asks for them explicitly via specifying the 'Component_Size.
This is pretty important, because there is already code out there
with pragma Packs, and we don't want it to suddenly start packing
differently...

> ... That's what this whole
> discussion has been about.
> 
> There's also the issue of whether you can say:
> 
>     for T2'Component_Size use 3;
> 
> instead of the pragma Pack above.

That is the only way to get packing to 3-bits-per-element with
the AverStar front end (unless you happen to have a 24-bit word,
like the Raytheon Patriot Missile Ground Support computer, where
3-bits-per-element is a "natural" size ;-).
> 
> - Bob

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: 3-bit array ...

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I must say I wonder if the GNAT (and now Averstar) decision is
> the right one. It would have been cleaner to say Pack always
> means 4, and you use a component size clause if you want 3.

It would be a Good Thing if all compilers did the same thing for sort of
thing.

> Bob, how far did Averstar go, did you just do 3 bits? In GNAt
> we close pack all sizes up to 64. (e.g. an array of Natural
> gets packed to 31, which can be quite a surprise, although the
> pragma Pack in this case is junk!)

I had better let Tucker answer that.  I've already given one piece of
misinformation in my original post.  I didn't do the work myself, so I
don't know the details.

- Bob

Re: 3-bit array ...

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <wccg0xgm5n4.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > GNAT has always
> > supported packing to the 3-bit level.  AverStar's front end,
> and the
> > Green Hills compiler that uses AverStar's FE, used to use 4,
> but now
> > uses 3, due to customer demand for it.  That's what this whole
> > discussion has been about.
> >
> > There's also the issue of whether you can say:
> >
> >     for T2'Component_Size use 3;
> >
> > instead of the pragma Pack above.
> 
> I must say I wonder if the GNAT (and now Averstar) decision is
> the right one. It would have been cleaner to say Pack always
> means 4, and you use a component size clause if you want 3.

Bob mis-spoke.  We only pack to "odd-ball" sizes if the user
explicitly requests it via a 'Component_Size clause.  This
is important because there is existing Ada 95 code which we didn't
want to suddenly change behavior in a potentially surprising way.

> But the gods of legacy Ada 83 code definitely demand significant
> sacrifices, so this is one of them.

We chose to force these "legacy" users to put in a 'Component_Size clause
if they really need the 3-bit (in)efficiency.

> Bob, how far did Averstar go, did you just do 3 bits? In GNAt
> we close pack all sizes up to 64. (e.g. an array of Natural
> gets packed to 31, which can be quite a surprise, although the
> pragma Pack in this case is junk!)

We support any "odd-ball" 'component_size up to the maximum integer 
size supported by the compiler on the target.  That varies, from 24 
bits up to 64 bits.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: 3-bit array ...

[Robert Dewar]

In article <wccg0xgm5n4.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> GNAT has always
> supported packing to the 3-bit level.  AverStar's front end,
and the
> Green Hills compiler that uses AverStar's FE, used to use 4,
but now
> uses 3, due to customer demand for it.  That's what this whole
> discussion has been about.
>
> There's also the issue of whether you can say:
>
>     for T2'Component_Size use 3;
>
> instead of the pragma Pack above.


I must say I wonder if the GNAT (and now Averstar) decision is
the right one. It would have been cleaner to say Pack always
means 4, and you use a component size clause if you want 3.

But the gods of legacy Ada 83 code definitely demand significant
sacrifices, so this is one of them.

Bob, how far did Averstar go, did you just do 3 bits? In GNAt
we close pack all sizes up to 64. (e.g. an array of Natural
gets packed to 31, which can be quite a surprise, although the
pragma Pack in this case is junk!)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 3-bit array ...

[Robert Dewar]

In article <384D4C8E.36174908@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Bob mis-spoke.  We only pack to "odd-ball" sizes if the user
> explicitly requests it via a 'Component_Size clause.  This
> is important because there is existing Ada 95 code which we
> didn't want to suddenly change behavior in a potentially
> surprising way.

Well GNAT has always packed tightly in response to the pragma,
so we did not have to worry about this effect. We have a lot of
legacy Ada 83 customers who either want to maintain Ada 83
conmpatibility, or are allergic to changing their code, which
is why we choose to pack always. Obviously at this stage we
could not consider changing, because we have so many users
depending on the tight packing.

I suppose a configuration pragma saying you want tight packing
or not is a possibility.


Sent via Deja.com http://www.deja.com/
Before you buy.

RE: 3-bit array ...

[Robert C. Leif, Ph.D.]

-----Original Message-----
From: USENET news [mailto:news@inmet.camb.inmet.com]On Behalf Of Tucker
Taft
Sent: Tuesday, December 07, 1999 10:06 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: 3-bit array ...

SNIP
Robert Dewar wrote:
To: Tucker Taft et al.
From: Bob Leif

Amusingly, IBM has now created a super-computer for the human genome using a
large number of special RISC processors. Three and possibly two bit
operations on a very wide word (at least 128 bit) CPU probably would have
been a better approach. One of the main uses is determining the degree of
matching between various parts of these arrays. Bounded Arrays of generic
characters would cover both BCD arithmetic and genomics. The present
packages for 8 and 16 bit characters could be instantiations, in a similar
manner as as was done for Text_Io with integers and floats.


Bob mis-spoke.  We only pack to "odd-ball" sizes if the user
explicitly requests it via a 'Component_Size clause.  This
is important because there is existing Ada 95 code which we didn't
want to suddenly change behavior in a potentially surprising way.

> But the gods of legacy Ada 83 code definitely demand significant
> sacrifices, so this is one of them.

We chose to force these "legacy" users to put in a 'Component_Size clause
if they really need the 3-bit (in)efficiency.

> Bob, how far did Averstar go, did you just do 3 bits? In GNAt
> we close pack all sizes up to 64. (e.g. an array of Natural
> gets packed to 31, which can be quite a surprise, although the
> pragma Pack in this case is junk!)

We support any "odd-ball" 'component_size up to the maximum integer
size supported by the compiler on the target.  That varies, from 24
bits up to 64 bits.

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA