Q re pack & aliased

Q re pack & aliased

[tmoran]

I need to make a packed array of aliased three byte objects.  Gnat 3.15p
tells me it won't pack (or set 'component_size) for aliased objects, and
it allocates four bytes/component.  How can I get around this limitation?

Re: Q re pack & aliased

[David Holm]

On Sun, 20 Apr 2003 01:08:13 GMT
tmoran@acm.org wrote:

> I need to make a packed array of aliased three byte objects.  Gnat 3.15p
> tells me it won't pack (or set 'component_size) for aliased objects, and
> it allocates four bytes/component.  How can I get around this limitation?

I'm no Ada expert just yet. But what about 'Unchecked_Access or 'Unrestricted_Access?
If you are doing something evil maybe 'Address would work too...

//David Holm

Re: Q re pack & aliased

[tmoran]

> > I need to make a packed array of aliased three byte objects.  Gnat 3.15p
> > tells me it won't pack (or set 'component_size) for aliased objects, and
> > it allocates four bytes/component.  How can I get around this limitation?
>
> I'm no Ada expert just yet. But what about 'Unchecked_Access or 'Unrestricted_Access?
> If you are doing something evil maybe 'Address would work too...
  I'm just trying to write portable Ada.  The problem isn't in the access,
it's in the declaration - Gnat won't accept it.  "packing" 24 bits objects
shouldn't be all that hard on a byte oriented (x86 Windows) machine.

Re: Q re pack & aliased

[Jacob Sparre Andersen]

tmoran@acm.org wrote:

>   I'm just trying to write portable Ada.  The problem isn't in the access,
> it's in the declaration - Gnat won't accept it.  "packing" 24 bits objects
> shouldn't be all that hard on a byte oriented (x86 Windows) machine.

x86 (with x different from "80" - and maybe also "802") is not all that 
byte oriented.

Jacob
-- 
"Banning open source would have immediate, broad, and
  strongly negative impacts on the ability of many sensitive
  and security-focused DOD groups to protect themselves
  against cyberattacks"                        -- Mitre Corp.

Re: Q re pack & aliased

[Vinzent Hoefler]

Jacob Sparre Andersen <sparre@crs4.it> wrote:

>x86 (with x different from "80" - and maybe also "802") is not all that 
>byte oriented.

Huh? Since when?

Of course it might be quite inefficient (even on the 8086) but
addresses are still byte[0]-sized on *all* x86.

The first True-Color-VGA had 24-bit-sized pixels. How would you have
addressed them?

[0] In the sense of 1 byte = 8 bits.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Q re pack & aliased

[tmoran]

>The first True-Color-VGA had 24-bit-sized pixels. How would you have
>addressed them?
  I have pre-Gnat 3.15p programs that ran with 24 bit pixels, so this
is apparently a new problem.  Would someone with a newer Gnat please
try the program below?  On 3.15p it gives a warning on aliased, and ignores
the packing.  Removing the word "aliased" makes it pack correctly.

with ada.text_io;
procedure testpack is
  type triples is range 0 .. 2**24-1;
  for triples'size use 24;
  type bunches is array(integer range <>) of aliased triples;
  pragma pack(bunches);
  x : bunches(1 .. 10);
begin
  ada.text_io.put_line(integer'image(x'size/80)
                       & " should = 3, not 4");
end testpack;

Re: Q re pack & aliased

[Stephen Leake]

tmoran@acm.org writes:

>   I have pre-Gnat 3.15p programs that ran with 24 bit pixels, so this
> is apparently a new problem.  Would someone with a newer Gnat please
> try the program below?  

stephe@anarres$ gnatmake -v testpack.adb 

GNATMAKE 3.16a (20030120) Copyright 1995-2002 Free Software Foundation, Inc.
  "testpack.ali" being checked ...
  -> "testpack.ali" missing.
gcc -c testpack.adb
testpack.adb:6:03: warning: pragma "pack" ignored, cannot pack aliased components
testpack.adb:7:03: warning: "x" is never assigned a value
End of compilation


Sorry. Apparently ACT felt the need to improve efficiency somewhere.
There may be a compiler switch to get back the old behavior. You could
try reporting it to report@gnat.com as a regression. I don't have any
older gnat versions handy.

-- 
-- Stephe

Re: Q re pack & aliased

[Robert A Duff]

Stephen Leake <Stephe.Leake@nasa.gov> writes:

> tmoran@acm.org writes:
> 
> >   I have pre-Gnat 3.15p programs that ran with 24 bit pixels, so this
> > is apparently a new problem.  Would someone with a newer Gnat please
> > try the program below?  
> 
> stephe@anarres$ gnatmake -v testpack.adb 
> 
> GNATMAKE 3.16a (20030120) Copyright 1995-2002 Free Software Foundation, Inc.
>   "testpack.ali" being checked ...
>   -> "testpack.ali" missing.
> gcc -c testpack.adb
> testpack.adb:6:03: warning: pragma "pack" ignored, cannot pack aliased components
> testpack.adb:7:03: warning: "x" is never assigned a value
> End of compilation
> 
> Sorry. Apparently ACT felt the need to improve efficiency somewhere.
> There may be a compiler switch to get back the old behavior. You could
> try reporting it to report@gnat.com as a regression. I don't have any
> older gnat versions handy.

Seems like the old and new behavior are the same.  In both versions, the
compiler refuses to pack aliased 24-bit components.  Or did I
misunderstand the ealier posting?

Anyway, I think what's going on here is that all aliased objects of a
given subtype *must* be represented the same way.  That's because when
you have a pointer in your hands, the compiler doesn't know what it
points to.  The code generated for X.all has to fetch a 24-bit quantity,
not knowing whether it's an array component, or whether the array is
packed.

The most efficient way to fetch 24 bits on this machine is to make sure
the thing is 32-bit aligned, with zeros or sign-extension in the extra 8
bits.  If you insist that the array-of-aliased be tightly packed, then
every X.all would have to be less efficient.  It's fine if references to
components of packed arrays are less efficient.  That's The whole point
of packing -- to allow slowness of array indexing in return for better
speed of copying or comparing the whole array and so forth.  But it's
not fine to make X.all slow even when X points to a component of an
unpacked array, or into the heap.

- Bob

Re: Q re pack & aliased

[tmoran]

>Seems like the old and new behavior are the same.  In both versions, the
>compiler refuses to pack aliased 24-bit components.  Or did I
>misunderstand the ealier posting?
  3.15p (& 3.16a) refuses to pack.  It generates a warning and then
ignores the pragma pack.  Replacing pragma pack with "'component_size
use 24" causes a fatal compilation error.
Prior to 3.15, it packed automatically without being asked (the
components have for xxx'size use 24, which I thought suggests that
I want them to be 24, not 32, bits.).  Janus similarly automatically
packs.  I tried it on OA 7.2.2 where pragma pack is silently ignored,
but 'component_size is properly obeyed without complaint.

>But it's not fine to make X.all slow even when X points to a component
>of an unpacked array, or into the heap.
  It's even less fine to make the program no longer run.  Something about
"make it work right, then worry about speed" ;)

  The original question was "How can I get around this limitation."
System.Address_To_Access_Conversions comes to mind, but seems awfully
heavy handed.  Compiling with no optimization makes no difference.

Re: Q re pack & aliased

[Matthew Heaney]

tmoran@acm.org wrote in message news:<Cjepa.568837$L1.166648@sccrnsc02>...
> >The first True-Color-VGA had 24-bit-sized pixels. How would you have
> >addressed them?
>   I have pre-Gnat 3.15p programs that ran with 24 bit pixels, so this
> is apparently a new problem.  Would someone with a newer Gnat please
> try the program below?  On 3.15p it gives a warning on aliased, and ignores
> the packing.  Removing the word "aliased" makes it pack correctly.
> 
> with ada.text_io;
> procedure testpack is
>   type triples is range 0 .. 2**24-1;
>   for triples'size use 24;
>   type bunches is array(integer range <>) of aliased triples;
>   pragma pack(bunches);
>   x : bunches(1 .. 10);
> begin
>   ada.text_io.put_line(integer'image(x'size/80)
>                        & " should = 3, not 4");
> end testpack;


Pragma Pack and aliased components don't really go together.  Think
about it: the pragma is there to tell the compiler not to allocate
array components on "natural" boundaries, which would otherwise be
addressable.

Get rid of the pragma Pack, and use a component size clause:

   type bunches is array (integer range <>) of aliased triples;
   for bunches'Component_Size use 24;

Pragma Pack is really intended to give a hint to the compiler that you
wish to make a space optimization -- do not use it to specify
representation.  That's what the T'Component_Size is for.

Don't use pragma Pack unless you know what you're doing.

Your program is broken.

Re: Q re pack & aliased

[Nick Roberts]

I think I have the solution!

I suggest that 'aliased' was always inappropriate anyway.

When you are declaring an object which will overlay a piece of memory that
will correspond to some external entity (e.g. an address range corresponding
to a memory-mapped I/O facility, such as a memory-mapped graphics device),
you do not need (or want) 'aliased', you need to mark the object (or its
static subtype) as 'volatile'. This is done with the Volatile pragma, see
RM95 C.6.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: Q re pack & aliased

[Nick Roberts]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1ec946d1.0304221451.6365ec93@posting.google.com...

> Pragma Pack and aliased components don't really go together.  Think
> about it: the pragma is there to tell the compiler not to allocate
> array components on "natural" boundaries, which would otherwise be
> addressable.

I agree with this.

> Get rid of the pragma Pack, and use a component size clause: ...

I agree with this.

I believe the correct solution is to drop the 'aliased' and the pragma Pack,
and use pragma Volatile and the appropriate representation clauses (e.g.
size clauses).

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: Q re pack & aliased

[tmoran]

> I suggest that 'aliased' was always inappropriate anyway.
>
> When you are declaring an object which will overlay a piece of memory that
> will correspond to some external entity (e.g. an address range corresponding
> to a memory-mapped I/O facility, such as a memory-mapped graphics device),
> you do not need (or want) 'aliased', you need to mark the object (or its
> static subtype) as 'volatile'. This is done with the Volatile pragma, see
  The case at hand is a DIBitmap in Windows.  It needs to be in packed, 24
bit, format so I can pass it to Windows (not to mention size
considerations).  I also need sometimes to make pointers to individual
elements, so the components need to be aliased.  There is no second task,
hardware or software, accessing it, so it's not Volatile.  The individual
component (pixel) is rep-speced to layout the red/green/blue parts, and to
say the @#$% thing is 24 bits in size.  That used to be enough to convince
all the compilers I tried that a pixel was in fact 24 bits.  The only
advantage of 'component_size over pragma pack in this case is that the
former generates a fatal compilation error with Gnat 3.15, the latter, a
warning and an incorrect program.  (In ObjectAda, however, 'component_size
does the desired thing, while pragma pack is ignored with no warning.
Janus packs as desired.  I'd be curious what happens with Rational or
Green Hills Windows targeted compilers.)

Re: Q re pack & aliased

[Vinzent Hoefler]

tmoran@acm.org wrote:

>  The case at hand is a DIBitmap in Windows.  It needs to be in packed, 24
>bit, format so I can pass it to Windows (not to mention size
>considerations).  I also need sometimes to make pointers to individual
>elements, so the components need to be aliased.

Well, why don't you do this, then?

|with Ada.Text_IO;
|
|procedure t is
|   type color is range 0 .. 2**8 - 1;
|   for color'Size use 8;
|
|   type triples is record
|      red,
|      green,
|      blue : color;
|   end record;
|   for triples'Size use 24;
|
|   type bunches is array (Integer range <>) of aliased triples;
|   x : bunches (1 .. 10);
|   for x'Size use 240;
|begin
|   x := (1 => (red => 0, green => 1, blue => 1), others => (0, 0, 0));
|   Ada.Text_IO.Put_Line (Integer'Image (x'Size / 80)
|                         & " should = 3, not 4");
|end t;

Probably some of the 'Size-attributes are not needed here (especially
the "x'Size use 240"-one), but I put them in to see if the compiler
warns about any of them. It doesn't and the generated code for the
assignment looks correct to me, too.

I don't know how this would fit into your existing code, but I guess,
a conversion between a 24-bit-type like you used before and the
triples-record is quite easy without breaking too much...


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Q re pack & aliased

[Martin Dowie]

> warning and an incorrect program.  (In ObjectAda, however, 'component_size
> does the desired thing, while pragma pack is ignored with no warning.
> Janus packs as desired.  I'd be curious what happens with Rational or
> Green Hills Windows targeted compilers.)

Won't GHS do the same as OA? don't they share the same front-end?

Re: Q re pack & aliased

[tmoran]

|   x : bunches (1 .. 10);
|   for x'Size use 240;
  Unfortunately, one rarely knows the width of an image file at
compile time.  What does your program print with and without
the "for x'Size use 240;"?

>a conversion between a 24-bit-type like you used before and the
>triples-record is quite easy without breaking too much...
  I'm sorry if that wasn't clear.  My "24-bit-type" is indeed
a record, just like your example.  The sole difference is the
addition of a specific layout for the color components:
    for Triple_Color_Type use record
        Blue  at 0 range 0 .. 7;
        Green at 1 range 0 .. 7;
        Red   at 2 range 0 .. 7;
    end record;

Dropping the word "aliased" and changing to:
--  type Triple_Color_Ptr_Type is access all Triple_Color_Type;
    package Gnat315_Workaround
      is new System.Address_To_Access_Conversions(Object=>Triple_Color_Type);
    subtype Triple_Color_Ptr_Type is Gnat315_Workaround.Object_Pointer;
    ...
    Image_Ptr : Triple_Color_Ptr_Type
--      := x(i)'Unchecked_Access;
      := Gnat315_Workaround.To_Pointer
           (x(i)'address);
makes the program work under Gnat, at the expense of ugliness, additional
special case documentation, and obscuring the fact that pixels are aliased.

Re: Q re pack & aliased

[Vinzent Hoefler]

tmoran@acm.org wrote:

>|   x : bunches (1 .. 10);
>|   for x'Size use 240;
>  Unfortunately, one rarely knows the width of an image file at
>compile time.

Yes, of course.

I just left it in to make sure the compiler does what it should do
even for the array. It doesn't really matter.

>  What does your program print with and without
>the "for x'Size use 240;"?

The same, it says "3 = ...". As it should. It makes no difference
either if the attribute is specified or not.

>  I'm sorry if that wasn't clear.  My "24-bit-type" is indeed
>a record, just like your example.  The sole difference is the
>addition of a specific layout for the color components:
>    for Triple_Color_Type use record
>        Blue  at 0 range 0 .. 7;
>        Green at 1 range 0 .. 7;
>        Red   at 2 range 0 .. 7;
>    end record;

Well, now it gets strange.

I just tried that and added the representation clause to the example
code I posted. It still compiles without any warning and seems to
generate the correct code, too.

I just tried it on both 3.15p for Windows and Linux.

But with your examplary 24-bit-type you used before both versions
(3.14 for Windows and 3.15 Win/Linux) showed the problem exactly as
you described here.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Q re pack & aliased

[Nick Roberts]

<tmoran@acm.org> wrote in message
news:63lpa.48072$Si4.30616@rwcrnsc51.ops.asp.att.net...

> > I suggest that 'aliased' was always inappropriate anyway.
> > ...

> The case at hand is a DIBitmap in Windows.  It needs to be in
> packed, 24 bit, format so I can pass it to Windows (not to
> mention size considerations).  I also need sometimes to make
> pointers to individual elements, so the components need to be
> aliased.
> ...
> There is no second task, hardware or software, accessing it,
> so it's not Volatile.

Ah. I beg your pardon.

I suspect that GNAT 3.15 (based on GCC 2.8.1?) now considers the minimal
addressable unit as a 'machine word' (32 bits), so it won't alias an object
(type) with components whose size isn't (a multiple of) this. But that's
just a guess.

Now I'll leave the argument! (Sorry.)

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: Q re pack & aliased

[Vinzent Hoefler]

"Nick Roberts" <nickroberts@blueyonder.co.uk> wrote:

>I suspect that GNAT 3.15 (based on GCC 2.8.1?) now considers the minimal
>addressable unit as a 'machine word' (32 bits), so it won't alias an object
>(type) with components whose size isn't (a multiple of) this.

Well, as I tried to demonstrate here at least the example code works
if the components of the record are byte sized.


Vinzent.