Re: 16 bit integers in streams

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

Tucker Taft wrote:
> 
> Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote:
> 
> : 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?
> 
> Gulp.  This would be a pretty big semantic effect for pragma Optimize.
> 
> The problem is that the representation used on streams is in one
> sense a very important "high-level" external effect, and in another
> sense something almost analagous to internal representation.

I assume size clauses control both the external and internal
representation; see below.

> I suspect the "right" solution is to consider the base range to be
> a 16 bit range for types like this, even though 32-bit arithmetic is
> used for them. We have already considered doing this, but haven't
> done it yet.  Of course, the longer we wait, the more people will 
> begin to rely on the current behavior...

Or complain about it :). Surely the intent of 'Read is to put the
_memory_ image of a type into the stream, not the _register_ image?
 
> Perhaps we could use an explicit size clause as a way to control
> the base range.  We have frequently debated the meaning of
> a "confirming" size clause.  Perhaps this could be one "real" effect
> of such a clause.  It's an intriguing thought...

This is definitely what I expect a size clause to mean; I'm telling the
compiler I want exactly 16 bits, anyplace it matters (including
streams). I assume that's what GNAT does now, although maybe GNAT is
also doing 16 bit arithmetic.

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

-- 
- Stephe