Re: 16 bit integers in streams

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

Tucker Taft wrote:
> ...
> In general, the existence of the base subtype is more of an > interesting
> frill than a core feature, but with streams, the characteristics of
> the base subtype suddenly become more important.  It's not clear
> how to resolve this dilemma...

If I can summarize:
	
Stream attributes 'Read and 'Write need to work for the base type,
because we can declare objects of type 'Base.

A size clause specifies the size of the first subtype, not the base
type. The base type can in general contain more bits than the first
subtype.

ObjectAda chooses 32 bit integers as the base type when I ask for 16 bit
integers, and therefore reads and writes 32 bits in streams.

This now makes sense (to me, anyway :). My original problem was that I
want to read a 16 bit integer from a stream (where the stream format is
dicated outside my Ada program). 

Clearly, if I was reading a 12 bit integer, I'd have to read two stream
elements and then do a shift and an unchecked conversion, and keep track
of the extra bits that are part of the next item in the stream.

I can take the same approach when reading a 16 bit integer, but I don't
have to if I use GNAT, which allows 16 bit base integers. The stream
format assumes I can read 16 bit chunks; it does not use smaller chunks.
Actually, I found another work around for ObjectAda; I can read
Wide_Characters, which are 16 bits, and then use 'Pos to get an integer.
But that's a bit of a kludge.

This gets back to the question of why ObjectAda uses 32 bit base
integers, when I give a range that fits in 16 bits and a size clause for
16 bits. Tucker said it was for "efficient arithmetic", but that's not
what I want in this case. It seems to me that specifying a size clause
should be enough of a hint to the compiler that I am willing to
sacrifice efficiency for the sake of control over size (in streams, in
this case). If you want more of a hint, I can add a pragma Optimize
(Space) (which I suggested earlier). Tuck said this would be a "large
semantic effect". I'm not clear what the problem is; the choice of base
integer size affects three things (that I know of):

1) The time efficiency of integer arithmetic.

2) Whether CONSTRAINT_ERROR is raised for intermediate results that are
outside the first subtype range. 

3) The number of bits read/written in streams. 

What else does it affect? 

If we let size clauses influence the choice of base integer type, we
have the following user control:

For 1), to let the compiler to choose a time efficient arithmetic type,
I just specify the range, and do NOT give a size clause. Similarly, for
2), I can specify a range that covers my intermediate results. 

For 3), I specify the number of bits I want, with the understanding that
it will be rounded up to the next hardware-supported integer size.


Perhaps a totally different solution would be to introduce yet another
stream attribute: 'Write_Sized, which respects the size clause, and thus
cannot be used on an object of a base type. 

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

-- 
- Stephe