Question about "for X'Size use ..."

Question about "for X'Size use ..."

[Darren New]

Let's say I declare
  type Blah is mod 2**12;
  for Blah'Size use 12;

Does that "for use" clause actually do anything? I.e., what does that
really mean on a CPU with 8-bit bytes? It doesn't change the size of
registers. Does it affect how things are written to streams?

I understand that if I pack an array or record or whatever, it makes a
difference. But is the compiler going to generate different code if a
Blah never winds up in an array or record or whatever? Will it be stored
in (say) a 16-bit location where it might be more efficient to use a
full 32 bits?

What if I say
  type Blah is mod 2**12;
  for Blah'Size use 64;
Does this have any effect? Is any compiler going to refuse to compile
those statements because it only has 32-bit registers?

TIA!

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
"You probably noticed you can't breath underwater. Hence the tank."
   -- PADI instruction manual, page 107.

Re: Question about "for X'Size use ..."

[Florian Weimer]

Darren New <dnew@san.rr.com> writes:

> Does that "for use" clause actually do anything? 

> Does it affect how things are written to streams?

There is no effect because the stream operations operate on the base
type, and you can't specify the size of a base type.

Re: Question about "for X'Size use ..."

[Robert Dewar]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote in message news:<tgzo999lta.fsf@mercury.rus.uni-stuttgart.de>...
> Darren New <dnew@san.rr.com> writes:

> There is no effect because the stream operations operate on the base
> type, and you can't specify the size of a base type.

This is incorrect, please see the latest AI on this topic

Re: Question about "for X'Size use ..."

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

>> There is no effect because the stream operations operate on the base
>> type, and you can't specify the size of a base type.
>
> This is incorrect, please see the latest AI on this topic

AI 270 is not a mere clarification, it changes the semantics of the
Ada language.  I don't think these become part of the language
automatically.

(I think that AI 270 is pointless.  Stream_Size won't give any
additional portability unless the order of stream elements can be
controlled, and the method of storing the sign, and the situations
were the range of type neither is not symmetric around zero.)

Re: Question about "for X'Size use ..."

[Larry Kilgallen]

In article <871ymk480x.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> dewar@gnat.com (Robert Dewar) writes:
> 
>>> There is no effect because the stream operations operate on the base
>>> type, and you can't specify the size of a base type.
>>
>> This is incorrect, please see the latest AI on this topic
> 
> AI 270 is not a mere clarification, it changes the semantics of the
> Ada language.  I don't think these become part of the language
> automatically.
> 
> (I think that AI 270 is pointless.  Stream_Size won't give any
> additional portability unless the order of stream elements can be
> controlled, and the method of storing the sign, and the situations
> were the range of type neither is not symmetric around zero.)

I have not worked with streams, but was wondering if anyone had tried
using ASN.1 to achieve interoperability.  It solves endian problems
and the DER representation is rather firm about "only one way to express
something".

It seems to me that Ada folk should be willing to build on existing
standards, where suitable.

Re: Question about

[Ted Dennison]

In article <dsGwyS7sA3+2@eisner.encompasserve.org>, Larry Kilgallen says...
>
>I have not worked with streams, but was wondering if anyone had tried
>using ASN.1 to achieve interoperability.  It solves endian problems
>and the DER representation is rather firm about "only one way to express
>something".

Is it? For instance, data can be encoded with lengths, or with an
"End-of-Contents" octet. 
The copy I have here is about 16 years old, and I don't have a "DER", just a
BER. My memory from when I did it was that there were indeed multiple ways to
encode most anything, but again that was many moons ago.

I'd think the big problems with ASN.1 streams would be:

o  ASN.1 is too damn complicated. 
o  The encoding data structures are too flexible to map directly into Ada.
o  Some ASN.1 types have no direct Ada analog.
o  Some Ada types have multipe possible ASN.1 analogs.
o  Since its type-based, you couldn't just do the job with a custom stream.
You'd also have to recode every type to output ASN.1 from its stream attributes.

The last is a bit of a problem for *any* custom stream in Ada. If you care about
the internal data types or things like record boundries, then you end up having
to rewrite all the type stream attributes. This is a lot of work. It also
prevents people from using just any type with your stream, and it prevents
anyone from using those types with any other streams that you may have lying
around.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Question about

[Larry Kilgallen]

In article <C7Rc7.5082$NJ6.23233@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <dsGwyS7sA3+2@eisner.encompasserve.org>, Larry Kilgallen says...
>>
>>I have not worked with streams, but was wondering if anyone had tried
>>using ASN.1 to achieve interoperability.  It solves endian problems
>>and the DER representation is rather firm about "only one way to express
>>something".
> 
> Is it? For instance, data can be encoded with lengths, or with an
> "End-of-Contents" octet. 
> The copy I have here is about 16 years old, and I don't have a "DER", just a
> BER. My memory from when I did it was that there were indeed multiple ways to
> encode most anything, but again that was many moons ago.

That is the basic difference between BER (Basic Encoding Rules) and
DER (Distinguished Encoding Rules).  Something which is valid DER is
also valid BER, but under DER there is only a single way to represent
something.

> I'd think the big problems with ASN.1 streams would be:
> 
> o  ASN.1 is too damn complicated. 

ASN.1 is quite susceptible to being compiled.  Thus it is regular,
if not particularly human-friendly.  I believe a compiler could
handle the job neatly -- no human hands need be involved.

> o  The encoding data structures are too flexible to map directly into Ada.
> o  Some ASN.1 types have no direct Ada analog.
> o  Some Ada types have multipe possible ASN.1 analogs.

My point is not that a general ASN.1 message would be acceptable as a
stream, but that a stream would be encoded as in ASN.1.  This gives a
great opportunity for the sending and receiving Ada implementations to
check whether the stream is in the proper format.

> o  Since its type-based, you couldn't just do the job with a custom stream.
> You'd also have to recode every type to output ASN.1 from its stream attributes.

I believe that could be built into the compiler, with as much congruence
as appropriate -- for instance, requiring that the names of elements be
the same on the sending and receiving systems (if that is desired).

> The last is a bit of a problem for *any* custom stream in Ada. If you care about
> the internal data types or things like record boundries, then you end up having
> to rewrite all the type stream attributes. This is a lot of work. It also
> prevents people from using just any type with your stream, and it prevents
> anyone from using those types with any other streams that you may have lying
> around.

I was under the impression that the program reading a stream was supposed
to "match" the program that wrote it, at least with respect to the type
declarations.  To me it seems those type declarations are enough to make
a definitive ASN.1 DER encoding.

Re: Question about "for X'Size use ..."

[Robert Dewar]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<dsGwyS7sA3+2@eisner.encompasserve.org>...
> I have not worked with streams, but was wondering if anyone had tried
> using ASN.1 to achieve interoperability.  It solves endian problems
> and the DER representation is rather firm about "only one way to 
> express something".

In GNAT, we use XDR in connection with Annex E to achieve complete
heterogenous interoperability for streams.

Re: Question about "for X'Size use ..."

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<871ymk480x.fsf@deneb.enyo.de>...
> (I think that AI 270 is pointless.  Stream_Size won't give any
> additional portability unless the order of stream elements can be
> controlled, and the method of storing the sign, and the situations
> were the range of type neither is not symmetric around zero.)

You are missing a lot here!

Indeed AI 270 is quite significant in achieving interoperability,
and was motivated by the fact that compilers were not interoperable
before (because of unexpectedly large base types), and now they
are. The mention of storing the sign is a bit bogus, given that
virtually all machines are twos complement now. More importantly
you now get complete interoperability for the type

   type x is range 0 .. 255;
   for x'size use 8;

which was not the case before

If you think an AI is pointless, you are probably missing something.
AI's don't get approved without a lot of very well informed highly
skeptical perusal and discussion by the ARG :-)

Re: Question about "for X'Size use ..."

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> The mention of storing the sign is a bit bogus, given that virtually
> all machines are twos complement now.

Hmm, the DSP on one of the sound cards lying around here is a
one-complement architecture, but you're right nevertheless.

> More importantly you now get complete interoperability for the type
>
>    type x is range 0 .. 255;
>    for x'size use 8;
>
> which was not the case before

But the cases in which one stream element is written are the only ones
which are specified completely.  The others still remain open.  I find
this highly undesirable.

With the current scenario, you don't even achieve cross-compiler
compatibility on the same architecture.  For example, a vendor might
have chosen to write integers generally in big-endian format,
independently of the preferred order of the architecture, to gain
cross-architecture compatibility for this compiler.

> If you think an AI is pointless, you are probably missing something.

Probably.  I'm still a bit irritated because people are dealing with
such issues and do not tackle the more eminent problem of specifying
the byte/octet order for discrete types (both in-memory representation
and stream I/O layout).

Re: Question about "for X'Size use ..."

[Larry Kilgallen]

In article <87ofpnzmpj.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:

> Probably.  I'm still a bit irritated because people are dealing with
> such issues and do not tackle the more eminent problem of specifying
> the byte/octet order for discrete types (both in-memory representation
> and stream I/O layout).

That's what I like about ASN.1.  I don't know XDR.

Re: Question about "for X'Size use ..."

[Toshitaka KUMANO]

For your interests.

Larry Kilgallen wrote:
> That's what I like about ASN.1.  I don't know XDR.

Thanks to XDR in GNAT, we have been able to exchange any arbitrary
data types among PowerPC (big endian) and Alpha (little endian), 
including record types where components are designated with
some non-natural bit width and location, such as,

type Data is
   record
      Bits_12 : Natural range 0 .. 2**12;
      Bits_20 : Natural range 0 .. 2**20;
   end record;

for Data use
   record
      Bits_12 at 0 range  0 .. 11;
      Bits_20 at 0 range 12 .. 31;
   end record;

for Data'Size use 32;

--
kuma

Re: Question about "for X'Size use ..."

[john mann]

I understood that packing pragmas were advice to the compiler and can be ignored.