Re: 16 bit integers in streams

[Stephen Leake <Stephen.Leake@gsfc.nasa.gov>]

Tucker Taft wrote:
> 
> Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote:
> 
> : ... Here's an attempt to force ObjectAda to read a 16 bit integer:
> 
> : with Ada.Streams;
> : package Interface_Streams is
> 
> :    type Integer_16 is range -32768 .. 32767;
> :    for Integer_16'Size use 16;
> 
> :    procedure Read_16
> :       (Stream : access Ada.Streams.Root_Stream_Type'Class;
> :        Item : out Integer_16);
> 
> :    subtype Integer_16_Base is Integer_16'base;
> :    for Integer_16_Base'Read use Read_16;
> 
> :    procedure Write_16
> :       (Stream : access Ada.Streams.Root_Stream_Type'Class;
> :        Item : in Integer_16);
> 
> :    for Integer_16'Write use Write_16;
> 
> : end Interface_Streams;
> 
> : For both attribute definition clauses, ObjectAda 7.1 gives the >   error:
> 
> : interface_streams.ads: Error: line 18 col 33 LRM:13.13.2(36), For an
> : attribute definition clause specifying a stream attribute for a > : scalar
> : type, the subtype  for the Item parameter must be the base subtype
> 
> Note that this is similar to declaring a 6 bit integer type.
> You presumably would not be surprised if the compiler used
> a base subtype of larger than 6 bits.  On most modern processors,
> the efficient arithmetic size is 32 or 64 bits, so less and less
> should you expect the base subtypes to be anything shorter than 32.

Yep, that's why I suspected the 32 bit base type.
 
> : ... Is it legal for
> : ObjectAda to reject these attribute definition clauses?
> 
> It is *required* to reject them, given that Integer_16'Base is not
> the same subtype as Integer_16.  In fact, even if Integer_16'Base'Size
> were 16, it would still be required to reject the above, since
> you didn't use Integer_16'Base.

But I DID use Integer_16'Base for Read (not for Write), at least with an
intevening subtype definition. I also tried:

   for Integer_16'Base'Read use Read_16;

and that gave the error:

interface_streams.ads: Error: line 12 col 19 LRM:13.3(5), The BASE
attribute is not a specifiable attribute

Is this a bug in ObjectAda? My maintenance contract has run out, but
I'll report it anyway.

> : I hope this issue can be addressed by the Uniformity Rapporteur > : Group;
> : it would be very nice if streams generated by one compiler/run-time
> : could be read by another. It would also be nice if a 16 bit integer
> : would read and write just 16 bits.
> 
> The fact that 'Read and 'Write use the base subtype rather than
> the first subtype for a scalar type is a bit problematic, but
> there are good reasons for it (of course ;-).  Basically you get
> only one 'Read attribute per *type*, and there is nothing prohibiting
> someone from declaring a variable using the 'Base subtype, so if the
> stream attributes are going to work for all subtypes of the type,
> they need to accommodate the 'Base subtype as well.
> 
> One possibility is to "pretend" the base subtype is only 16 bits,
> even though 32-bit arithmetic and 32-bit registers are used
> for all calculations.  This would bring the stream behavior
> back to where it only wrote 16 bits per item, but the meaning
> of 'Base would be somewhat muddied.

Ok, I understand the consistency issue. Apparently GNAT uses 16 bit base
integers when I request them. I hearby request an option on ObjectAda
(and therefore the AdaMagic front end?) to sacrifice efficient integer
arithmetic, and give me 16 bit base integers (when appropriate), and
therefore 16 bits in streams! Could pragma Optimize (Space) do this?

> The URG is no longer an active group.  The ARG is taking up the slack,
> and there will probably be AIs that address implementation advice,
> as opposed to implementation requirements.

So does this qualify as an AI? I guess I should just submit it and see
what happens.

> 
> --
> -Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
> Intermetrics, Inc.  Burlington, MA  USA

Thanks for your clear and detailed response; it is always a pleasure
when you post to comp.lang.ada.

-- 
- Stephe