aliased & packed?

aliased & packed?

[Tom Moran]

Clearly you can't do it.  I'd like to use pragma Pack for bits in a
black/white bitmap array.  That's easy to manipulate.  But to actually
display it I need to do a system call and pass the address.  If it
wasn't packed, Image'unchecked_access would be appropriate.  But
that won't work because Image would have to be aliased, and it can't
be because it's packed. Must I drop 'Pack' and make it an array of
bytes and do my own masking, shifting, etc?  What's the cleanest/most
portable/best way to accomplish the task?

Re: aliased & packed?

[Stephen Leake]

Tom Moran wrote:
> 
> Clearly you can't do it.  I'd like to use pragma Pack for bits in a
> black/white bitmap array.  That's easy to manipulate.  But to actually
> display it I need to do a system call and pass the address.  If it
> wasn't packed, Image'unchecked_access would be appropriate.  But
> that won't work because Image would have to be aliased, and it can't
> be because it's packed. Must I drop 'Pack' and make it an array of
> bytes and do my own masking, shifting, etc?  What's the cleanest/most
> portable/best way to accomplish the task?

Since the system call wants the address, use 'address (converted to
Long_Integer or whatever is required). You have to do some conversion to
pass to a system call; converting from 'unchecked_access is no "cleaner"
than converting from 'address.

As for portability, there will be a different system call to display
bitmaps, so you'll have to change a lot more than the attribute!
-- 
- Stephe

Re: aliased & packed?

[Tom Moran]

> As for portability, there will be a different system call to display
> bitmaps, so you'll have to change a lot more than the attribute!
Oops, I meant portability among Ada compilers, not across OSes or
hardware.

Re: aliased & packed?

[Robert Dewar]

Tom Moran said

<<Clearly you can't do it.  I'd like to use pragma Pack for bits in a
black/white bitmap array.  That's easy to manipulate.  But to actually
display it I need to do a system call and pass the address.  If it
wasn't packed, Image'unchecked_access would be appropriate.  But
that won't work because Image would have to be aliased, and it can't
be because it's packed. Must I drop 'Pack' and make it an array of
bytes and do my own masking, shifting, etc?  What's the cleanest/most
portable/best way to accomplish the task?>>

I don't understand, what is Image? The whole array? Of course you can
take the access of a packed array, but then the *array* needs to be
aliased, not its components. The components only need to be aliased
if you need the access of individual array elements, but clearly that
makes no sense if the elements are on arbitrary bit boundaries.

If what you want to do makes sense here, it can be done, please explain
more clearly what you are trying to do precisely!

Re: aliased & packed?

[tmoran]

>take the access of a packed array, but then the *array* needs to be
>aliased, not its components. The components only need to be aliased
>if you need the access of individual array elements, but clearly that
>makes no sense if the elements are on arbitrary bit boundaries.
  Given
type Image_type is array(0 .. last_row, 0 .. last_col) of aliased BW_Bit_type;
pragma Pack(Image_Type);
  If you want to pass, say, the right half of the fifth scan line,
The_Image(4, 320 .. 639), which is done in Windows by passing
the address of The_Image(4,320).  (320 being divisible by 8)

  Or look at ARM B.3(23), where char_array is defined as a packed array
of aliased 'char'.  Is this different except in the empirical sense
that on most machines a char is addressable and a bit is not?

  Having been bitten in the past by passing an array to an external
function, and finding the external function looking at a descriptor
when it thought it was looking at the first data element, my coding
style has evolved to pass the address of the first data element
instead.  Is this no longer necessary with any correct Ada 95 compiler?

  It was suggested that 'address be used instead of 'access.  Do the
rules of Ada say that should always work, on any compiler, for an
Imported function?  Clearly 'address and 'access are not normally
assumed identical (or there would be no point to
System.Address_To_Access_Conversions).

Re: aliased & packed?

[Robert Dewar]

Tom Moran said

<<  It was suggested that 'address be used instead of 'access.  Do the
rules of Ada say that should always work, on any compiler, for an
Imported function?  Clearly 'address and 'access are not normally
assumed identical (or there would be no point to
System.Address_To_Access_Conversions).>>

Well, address is very precisely defined in terms of storage units
occupied, so its meaning, though target dependent of course, should
certainly be compiler independent assuming the same data layouts.

Note this assumption, there is nothing in Ada that specifies the
mapping of array elements, so any time you make an assumption about
this, you are writing implementation dependent code.

In the case of packed arrays, since none of the languages you are
interfacing to support packed arrays, pragma Convention does not
help to guarantee the order.

Obviously you definitely CANNOT expect access to work on a packed array.
This in fact is a good example of why access values and pointers are
totally different. In writing 'access of a packed aliased array element
and expecting it to work, you are making the typical mistake of thinking
of the 'access as being a pointer, and assuming that the pointer is 
implemented as an address.

It is quite clear that 'Address is *far* more appropriate in any case
for the use you have in mind, and is exactly at the right level of
abstraction.

Re: aliased & packed?

[Tom Moran]

> Well, address is very precisely defined in terms of storage units
> occupied, so its meaning, though target dependent of course, should
> certainly be compiler independent assuming the same data layouts.
  Which still does not answer my question of whether I can assume
that 'address will generate the right thing for an Imported C function,
especially when I see that many such C functions are defined in various
examples I see as taking 'access rather than 'address parameters.

> Obviously you definitely CANNOT expect access to work on a packed array.
  Does that mean I can't expect Interfaces.C
type char_array is array(size_t range <>) of aliased char;
pragma Pack(char array);
  to work?

Also, how about the question of 'address or 'access of the array itself
rather than a component (eg the first element).  Is either or both of
'address or 'access, in Ada 95, supposed to give an Imported function
the address of the first data element, rather than the address of a
descriptor?

Re: aliased & packed?

[Robert Dewar]

Tom Moran says

<<type char_array is array(size_t range <>) of aliased char;
pragma Pack(char array);
  to work?>>

Of course it will work. But what do you mean by working? There is no 
requirement in this case that the pragma Pack have any effect. Indeed
on most byte addressable machines, the pragma Pack will have no effect
anyway.

with GNAT, pragma Pack never has any effect if the components are aliased,
and indeed you will get a warning that the pragma Pack is ignored.

However, it is not silly to put it in necessarily, since you can imagine
a machine that allows independent addressability of characters, but 
still has a cost associated with 8-bit packing of characters. The old
alpha comes close to being like that, but actually on the Alpha, we decide
to pack this by default anyway.

Re: aliased & packed?

[Robert A Duff]

In article <dewar.863449539@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>However, it is not silly to put it in necessarily, since you can imagine
>a machine that allows independent addressability of characters, but 
>still has a cost associated with 8-bit packing of characters. The old
>alpha comes close to being like that, but actually on the Alpha, we decide
>to pack this by default anyway.

I'm curious: How much is the cost, on the alpha, of accessing the array
by 8-bit bytes?  And which models of Alpha are we talking about, and
when did they come out?  I only have the very early description of the
alpha architecture, so I have no idea what's the difference between the
21x64, for various x.

- Bob

Re: aliased & packed?

[Robert A Duff]

In article <1997May13.065907.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>But that is for somebody who wants _only_ a single byte.  In a great
>many programs one wants several bytes in succession, and once a longword
>or quadword has been loaded it can be shifted and masked several times to
>produce the desired bytes.  Since one memory access can produce up to
>8 bytes, there is a clear performance benefit on a newer machine for
>many programs to _avoid_ byte memory accesses.

Is this really true?  I mean, if you access one byte at the start of a
word (using byte instructions on the 21164), then won't the next seven
be sitting there in the cache waiting for you?

And it seems like more than a couple of instructions to shift and mask
an 8-byte word (I mean, using 21064 instructions only), in the case
where the byte you want is dynamic (i.e. you're indexing randomly into
an array of bytes -- on the other hand, most array accesses are probably
sequential).

>Which I believe supports my claim that this a compatibility rather than
>a pure performance move.

Quite likely true.  ObAda: I doubt it was compatibility with Ada's rules
about tasking and independent addressability that drove the decision.
;-)

- Bob

Re: aliased & packed?

[Larry Kilgallen]

In article <EA4nII.803@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

> Is this really true?  I mean, if you access one byte at the start of a
> word (using byte instructions on the 21164), then won't the next seven
> be sitting there in the cache waiting for you?

Good point.  I don't know what they have in there, but probably they
have that.  Of course registers are still faster than cache.

> And it seems like more than a couple of instructions to shift and mask
> an 8-byte word (I mean, using 21064 instructions only), in the case
> where the byte you want is dynamic (i.e. you're indexing randomly into
> an array of bytes -- on the other hand, most array accesses are probably
> sequential).

From what I have seen (several years ago), the register-to-register
instructions on Alpha look quite weird but many of them have clever
uses in such operations.  The instruction set was designed with heavy
input from compiler writers.

Larry Kilgallen

Re: aliased & packed?

[Robert Dewar]

Larry said

<<The original machines uses the 21064 chip, with Loads and Stores being
at a minimum of 32 bit granularity.  Having loaded the desired 32 bits
it takes a couple of instructions to shift and mask the desired byte
into having a register all to itself.  Storing requires reading the
old value first, combining, and writing.>>

One further comment on this issue. If you use 8-bit characters, it is not
so bad to load and store 8-bits. What is truly horrible is guaranteeing
independence. That is very expensive. 

BUT, the pragma Pack, even if it does not make any difference from a storage
representation point of view, does mean that you no longer have to provide
independence -- so this is the very valuable function of pragma Pack on 
things like char_array and string.

Re: aliased & packed?

[Richard Kenner]

In article <EA4nII.803@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>And it seems like more than a couple of instructions to shift and mask
>an 8-byte word (I mean, using 21064 instructions only), in the case
>where the byte you want is dynamic (i.e. you're indexing randomly into
>an array of bytes -- on the other hand, most array accesses are probably
>sequential).

The actual number of instructions depends on more than just if the byte
number (address mod 4) is known, but also on the form you have the address
in and on the value of the constant byte number, if known.

In most cases, byte loads are two instructions for both the static and
dynamic case.  For stores, it's between four and six instructions, with
the static case having four or five and the dynamic case six.