Re: Problem to dramatize packed-array/rep-clause difficulties

Re: Problem to dramatize packed-array/rep-clause difficulties

[tmoran]

In <4jankp$30h@ra.nrl.navy.mil> Doug Rogers gave an unaccepted-by-his-
compiler solution to a problem.  Here is an alternate for his specific
problem which at least my compiler accepts - I don't know about Dougs.

These are the nine-bit changes, similar logic handles the six bit ones.
Its elegance, of course, is in the eye of the beholder.  ;)

Assume since bits are specified in Intel order that bytes are also, ie,
that the low order bit of the second byte is in fact the highest order
bit of the first Natural9 value, rather than its lowest order bit.

--type High_Res_Data is array (Natural range 0 .. 7) of Natural9;

  type High_Res_Data is record
    a:Natural9;
    b:Natural9;
    c:Natural9;
    d:Natural9;
    e:Natural9;
    f:Natural9;
    g:Natural9;
    h:Natural9;
  end record;

  for High_Res_Data use record
    a at 0 range 0 .. 8;
    b at 1 range 1 .. 9;
    c at 2 range 2 .. 10;
    d at 3 range 3 .. 11;
    e at 4 range 4 .. 12;
    f at 5 range 5 .. 13;
    g at 6 range 6 .. 14;
    h at 7 range 7 .. 15;
  end record;
  for High_Res_Data'size use 72;

  ...

      when High =>
--      for Index in High_Res_Data'range loop
--        Put ("  Data (");
--        Put (Natural (Index), Width => 1);
--        Put (") => ");
--        Put (Natural (S.High_Res (Index)));
--        New_Line;
--      end loop;
        Put_Line("  Data (0) =>" & Natural9'image(S.High_Res.a));
        Put_Line("  Data (1) =>" & Natural9'image(S.High_Res.b));
        Put_Line("  Data (2) =>" & Natural9'image(S.High_Res.c));
        Put_Line("  Data (3) =>" & Natural9'image(S.High_Res.d));
        Put_Line("  Data (4) =>" & Natural9'image(S.High_Res.e));
        Put_Line("  Data (5) =>" & Natural9'image(S.High_Res.f));
        Put_Line("  Data (6) =>" & Natural9'image(S.High_Res.g));
        Put_Line("  Data (7) =>" & Natural9'image(S.High_Res.h));
    end case;
-----------------------------------

Re: Problem to dramatize packed-array/rep-clause difficulties

[Doug Rogers]

>  for High_Res_Data use record
>    a at 0 range 0 .. 8;
>    b at 1 range 1 .. 9;
>    c at 2 range 2 .. 10;
>    d at 3 range 3 .. 11;
>    e at 4 range 4 .. 12;
>    f at 5 range 5 .. 13;
>    g at 6 range 6 .. 14;
>    h at 7 range 7 .. 15;
>  end record;
>  for High_Res_Data'size use 72;

While I use this technique on small arrays, it's not easily
expanded to my real application, which has hundreds of these
items, each of which is a two-component record totalling 9 bits.
And I must handle other arrays (not the Ada keyword, 'cause I
wouldn't want to specify the solution instead of the problem,
huh, RD? ;-) of weird record sizes (homogeneous within the array).
As Robert Dewar pointed out in a private message, I didn't
specify this well enough.  If I must, I will employ this kind
of record on a grand (pardon the pun) scale, with "case"
statements everywhere, etc.  Not elegant, but it definitely
stays within the realm of Ada83.

Thanks for your input.

dr

Re: Problem to dramatize packed-array/rep-clause difficulties

[Robert Dewar]

Doug Rogers says

"As Robert Dewar pointed out in a private message, I didn't
specify this well enough.  If I must, I will employ this kind
of record on a grand (pardon the pun) scale, with "case"
statements everywhere, etc.  Not elegant, but it definitely
stays within the realm of Ada83."

Well what you are really talking about here is a repeated pattern
of nine byte containing eight fields, so clearly the best approach
if you have such a strange structure (it is one for which I have
never seen anyting in the real world that would correspond, so it
is not surprising that no one else ever asked for this), is to
define an array of these nine byte values, using your case
statement to select the right one of the eight fields. This
is quite easy to program, and incidentally results in the most
efficient possible code. I think you will find that in fact
you get much MORE efficient code this way than you would from
a compiler that supports this kind of jamming (p.s. all Alsys
compilers have always supported this).

And that is really the point here I think. You want to restrict
a compiler's acceptable of rep clauses to things that are close
to the machine and that it can do better than you can. 

Consider by analogy that typical computer languages have a built
in add operator, but do not have a built-in Bessel function operator.

Re: Problem to dramatize packed-array/rep-clause difficulties

[Robert Dewar]

tmoran said

"Assume since bits are specified in Intel order that bytes are also, ie,
that the low order bit of the second byte is in fact the highest order
bit of the first Natural9 value, rather than its lowest order bit."

Actually the ranges specified here are quite endian-neutral.

This set of rep clauses certainly works fine on GNAT, should work on
all versions of GNAT -- it's a bug (send it in to report@gnat.com)
if it doesn't, but it works fine for me!

Re: Problem to dramatize packed-array/rep-clause difficulties

[tmoran]

>Well what you are really talking about here is a repeated pattern of
>nine byte containing eight fields, so clearly the best approach ...
>if you have such a strange structure (it is one for which I have
  Of course an array of n bit fields will always have the packing
pattern repeat after Least Common Multiple(n,8) bits, and thus
can be viewed as an array of LCM(n,8)/8 -byte records, each containing
LCM(n,8)/n fields.  If access to the J-th of a packed array of n-bit
items is most efficiently implemented on a particular machine by using
a case statement on the J/(LCM(n,8)/n)-th group, then by definition a
'smart' compiler for that machine does it that way.

Re: Problem to dramatize packed-array/rep-clause difficulties

[Robert Dewar]

tmoran says

"  Of course an array of n bit fields will always have the packing
pattern repeat after Least Common Multiple(n,8) bits, and thus
can be viewed as an array of LCM(n,8)/8 -byte records, each containing
LCM(n,8)/n fields.  If access to the J-th of a packed array of n-bit
items is most efficiently implemented on a particular machine by using
a case statement on the J/(LCM(n,8)/n)-th group, then by definition a
'smart' compiler for that machine does it that way."

I disagree. It is *extremely* unlikely that any Ada compiler that *did*
implement jamming of 9-bit packed arrays would to it this way. Certainly
the only Ada compilers that I have seen that do support such packed
arrays do not take this approach. Supporting 9-bit packed arrays is
hard work anyway, doing it in the manner that tmoran suggests would
add a LOT of work to a compiler implementation for a an extremely
marginal feature.

And that is really the point. You want to limit the requirements for
implementation of rep clause level features to those cases which the
compiler can do efficiently without remarkable optimization effort.
Most programers do not like to rely on "big" optimizations of this
type.

If you want to use the LCM method, then you can perfectly easily 
program it yourself, and it will be comparably efficient to what
the compiler could do. It's a bit like the RISC situation. In
choosing the primitives of the language, we choose those things
which you cannot easily and efficiently add on as packages, but
you don't build in things which can easily be added as packages,
because it's very hard to decide what this set shoud be, and
more to the point, why make the compiler more complex for no
real gain.

Re: Problem to dramatize packed-array/rep-clause difficulties

[tmoran]

In <dewar.828029845@schonberg> Robert Dewar said:
>It is *extremely* unlikely that any Ada compiler that *did*
>implement jamming of 9-bit packed arrays would to it this way.
  Frankly, I was surprised to hear you say that the LCM method would be
the most efficient on modern CPUs, but you're the compiler writer.  If
ACT doesn't find it worthwhile to support 9-bit packed arrays in any
way, least of all the LCM way, that's certainly their business decision
to make.  The originator of this thread might, or might not, be unhappy
if all compilers supported pragma pack, but in suboptimal ways.