CVS difference for ais/ai-00195.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00195.txt

--- ais/ai-00195.txt	1998/10/01 00:24:30	1.2
+++ ais/ai-00195.txt	1998/10/01 03:20:23	1.3
@@ -656,3 +656,812 @@
                         Randy.
 
 ****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Friday, April 10, 1998 4:28 PM
+Subject: 	AI-195; Stream representation for scalar types
+
+At the recent ARG meeting, we discussed resolving AI-195 by introducing
+the notion of "stream base range" rather than simply "base range"
+to determine the default representation for scalar types in a stream.
+The stream base range would be determined strictly by the first subtype
+'Size, rounded up to some multiple of the stream element size in bits.
+
+This seems to me like a good solution to the problem that int-type'Base'Size
+might always be 32-bits on modern RISC machines, even though users 
+expect integer types with first subtype 'Size of 9..16 or 1..8 bits to
+be represented in the stream with 16 or 8 bits per item, respectively.
+
+I would like to make this change to our compiler sooner rather than later.
+Are there any "morning after" concerns about this approach?
+
+Also, it would be nice to settle soon on the details for cases like
+
+   type Three_Bytes is range -2**23 .. +2**23-1;
+
+Presuming that a stream element is 8 bits, should Three_Bytes'Write
+write 3 bytes or 4?  I.e., when rounding up the first subtype 'Size
+to a multiple of Stream_Element'Size, should we round up to some
+power-of-2 times the Stream_Element'Size, or just the next
+multiple?
+
+I have used first-subtype'Size above intentionally, presuming that
+if the user specifies a first-subtype'Size, then we would use that
+specified 'Size to affect the number of stream elements per item.
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 4:37 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<This seems to me like a good solution to the problem that int-type'Base'Size
+might always be 32-bits on modern RISC machines, even though users
+expect integer types with first subtype 'Size of 9..16 or 1..8 bits to
+be represented in the stream with 16 or 8 bits per item, respectively.
+>>
+
+Very few machines are in this category by the way, so this is a marginal
+concern.
+
+What machine are you thinking of here?
+
+I am a bit dubious about this change ...
+
+****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Friday, April 10, 1998 4:47 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+> What machine are you thinking of here?
+
+For essentially all modern RISC machines, all arithmetic is done in
+32 bits, and the only overflow bit or signal available relates
+to overflowing 32 bits.  Presuming 'Base'Size reflects the size of 
+arithmetic intermediates, 'Base'Size might very well be 32 for all integer 
+types, even for integer types declared with tiny ranges.
+
+> I am a bit dubious about this change ...
+
+Please elaborate.  
+
+Note that this is a real problem now, because some Ada 95 compilers
+are using 32 bits per item for all integer types in streams, even for
+those whose first subtype'Size is less than or equal to 16 bits.
+This is because 'Base'Size is 32 bits to reflect the register size,
+as seems reasonable.  Even among "CISC" machines, there are few
+these days that actually provide any kind of efficient 16- or 8-bit
+arithmetic, so presumably if overflow is being detected, it is
+associated with exceeding 32-bit values, not 16- or 8-bit values.
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 5:46 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<For essentially all modern RISC machines, all arithmetic is done in
+32 bits, and the only overflow bit or signal available relates
+to overflowing 32 bits.  Presuming 'Base'Size reflects the size of
+arithmetic intermediates, 'Base'Size might very well be 32 for all integer
+types, even for integer types declared with tiny ranges.
+>>
+
+It seems a bad choice to me to make the base types 32-bits. Because of
+the permission for intermediate values to exceed the base range, there
+really is no reason to do this.
+
+<<Note that this is a real problem now, because some Ada 95 compilers
+are using 32 bits per item for all integer types in streams, even for
+those whose first subtype'Size is less than or equal to 16 bits.
+This is because 'Base'Size is 32 bits to reflect the register size,
+as seems reasonable.  Even among "CISC" machines, there are few
+these days that actually provide any kind of efficient 16- or 8-bit
+arithmetic, so presumably if overflow is being detected, it is
+associated with exceeding 32-bit values, not 16- or 8-bit values.
+>>
+
+I agree that is a very bad choice, and is one of the reasons why I think
+it is a bad choice to have a single 32-bit base type.
+
+The statement about CISC machines is incorrect, the x86 provides the
+same efficiency for 8-bit arithmetic with overflow detection as for 
+32-bit arithmetic with overflow detection, and 16-bit ariythemtic
+with overflow detection is only very slightly less efficient.
+
+... so the presumably here is wrong.
+
+I really don't see the issue here. If you have
+
+  type x is range -128 .. +127;
+
+it is appropriate to use a one byte base type on nearly all machines (the
+now obsolete old alphas and now obsolete AMD 29K are the only exceptions
+among general purpose RISC machines).
+
+If you have
+
+  y,z : x;
+
+and you write
+
+  y := z + 35;
+
+then the code to check for contraint error is exactly the same for the
+case of x being derived from a 32-bit base type as if it is derived from
+an 8-bit base type.
+
+We seem to be asked here to patch up the language to deal with what basically
+sounds like just a wrong decision in choice of base types. That is why I
+am dubious about the need for the extra complexity.
+
+Tuck, can you be more clear on why it ever makes sense to follow this 
+approach of having a single 32-bit base type.
+
+****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Friday, April 10, 1998 6:00 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+The ARG discussed this after you left, and concluded roughly what
+I presented.  I was confirming their decision.  The basic point is
+that base ranges are possibly based on what is efficient to store
+for intermediates.  This is very different from what would be efficient
+for a stream representation.  The Patriot is a 24-bit machine, but it
+makes sense for stream elements to be 8 bits on that machine, and for
+only 8 bits to be used for "8-bit" integer types.  Nevertheless,
+'base'size is definitely 24 bits for such machines.
+
+On many RISC machines, loading, storing, and passing objects of less 
+than 32-bits can be less inefficient.  For such machines, it makes
+sense for 'Base'Size to be 32 bits even for tiny ranges.
+
+The point is to divorce the 'base'size from the stream element representation.
+Connecting the two seems like a mistake, particularly since there is
+no guarantee that you *won't* get constraint error when writing a value
+stored in a variable of the 'Base subtype, since it is allowed to be
+outside of 'Base'Range in any case (since it is unconstrained).
+
+-Tuck
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, April 10, 1998 6:15 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<On many RISC machines, loading, storing, and passing objects of less
+than 32-bits can be less inefficient.  For such machines, it makes
+sense for 'Base'Size to be 32 bits even for tiny ranges.
+>>
+
+Please site details, I don't see this. It is certainly not true for
+MIPS, SParc, HP, Power, x86, ALpha (new Alpha), ...
+
+I would be interested in Tuck backing up this claim, because the need for
+a new language feature really depends on the validity of this claim, which
+seems dubious to me!
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Saturday, April 11, 1998 8:06 AM
+To: 	dewar@gnat.com
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+I'm astonished that Robert thinks T'Base should be less than the 32-bit
+range (assuming it's big enough), for most 32-bit architectures.  (OK,
+on a 386, an 8-bit base range makes sense, but that's unusual.)  It
+seems to me that T'Base should reflect the range of intermediate results
+-- that was certainly the intent.
+
+A useful idiom in Ada 95 is:
+
+    type Dummy_Count is range 1..10_000;
+    subtype Count is Dummy_Count'Base range 1..Dummy_Count'Base'Last;
+    Number_Of_Widgets: Count := 1;
+
+which means "I want Count to be a positive integer, at least up to
+10_000, but there's no harm in giving me more than 10_000, so please use
+the most efficient thing."
+
+On most machines, I would expect Count'Last to be 2**31-1 (even though
+in-memory variables could be stored in 16 bits).  Any other value for
+Count'Last will result in an unnecessary (software) constraint check on:
+
+    Number_Of_Widgets := Number_Of_Widgets + 1;
+
+I see no reason for Dummy_Count'Base being -2**15..2**15-1.  Why, for
+example, is that any more sensible than -10_000..10_000, which is the
+smallest range allowed for the base range by the RM?
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Saturday, April 11, 1998 8:27 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<I'm astonished that Robert thinks T'Base should be less than the 32-bit
+range (assuming it's big enough), for most 32-bit architectures.  (OK,
+on a 386, an 8-bit base range makes sense, but that's unusual.)  It
+seems to me that T'Base should reflect the range of intermediate results
+-- that was certainly the intent.
+>>
+
+It is not surprising that Bob Duff is surprised by this, because it is 
+closely related to the whole business of the "wrong" size stuff in the RM.
+
+It is a significant mistake in an implementation to by default have objects
+of a subtype occupy less space than the type will occupy. This is becase
+it is highly incompatible with nearly all Ada 83 implementations.
+
+Consider:
+
+   type x is record
+     a : Natural;
+     b : Natural range 1 .. 10;
+     c : Character;
+   end record;
+
+Nearly all Ada 83 compilers will allocate 32 bits for b.
+
+Now in Ada 95, we are forced to consider the size of the type of b to be
+4 bits, and it would seem natural to allocate one byte, but this will
+cause horrible compatibility difficulties.
+
+We introduced Object_Size in GNAT to partially get around this (you see the
+difficulty is that if your compiler *does* feel like allocating 8 bits
+for that Natural field, there is no way to stop it. Even if you do:
+
+   subtype N10 is Natural range 1 .. 10;
+
+there is no way in Standard Ada 95 to override the size of N10 anyway.
+
+It was a big mistake to require the type sizes to be wrong with respect
+to Ada 83 (one I complained loudly and repeatedly about I might say :-)
+
+Indeed we had recently in GNAT to introduce a new attribute VADS_Size
+and a pragma Use_VADS_Size to provide additional tools for getting around
+this annoying incomaptibility (easily the biggest incompatibility between
+Ada 83 and Ada 95 in practice).
+
+But back to what a compiler should do.
+
+To me, the base type in Ada 83 (and Ada 95) is most naturally considered
+to be the size used to *store* things. Intermediate values are allowed
+to be bigger explicitly in 11.6 for this very reason (this was the original
+thought behind the permission in 11.6, and we explcitly discussed machines
+where most naturally arithmetic is done in higher precision).
+
+You definitely want objects declarecd as
+
+  type m is range 1 .. 10;
+  mm : m;
+
+to occupy 8 bits on nearly all machines.
+
+Bob Duff's model of this (and apparently Tuck's too) is to make sure that
+the subtype size is small enough, and then condition the object size on
+the subtype size. But as described above, that is simply too incomaptible
+with Ada 83 to be tolerable.
+
+All the Ada 83 compilers I am familiar with provided 8- and 16-bit base
+types for machines like the Sparc. We did discuss in Alsys the possibility
+of having only one base type, and indeed we concluded that it would be
+valid from the RM, but we quickly decided that there were all sortsw of
+problems with this approach.
+
+The problem with stream attributes is typical of the kind of things that
+go wrong if you think this way.
+
+<<<<I'm astonished that Robert thinks T'Base should be less than the 32-bit
+range (assuming it's big enough), for most 32-bit architectures.  (OK,
+on a 386, an 8-bit base range makes sense, but that's unusual.)  It
+seems to me that T'Base should reflect the range of intermediate results
+-- that was certainly the intent.
+>>
+>>
+
+It may be the intent of the designers of Ada 95, but if so, it is a definite
+distortion of the original intent.
+
+Note that you *certainly* don't believe this for the floating-point case.
+I cannot imagine anyone arguing that there should only be one floating-point
+type (64-bit) on the power architecture, because all intermediate results
+in registers are 64-bits.
+
+I similarly cannot imagine anyone arguing that there should be only one
+80-bit floating-point base type on the x86, on the grounds that this is
+the only type for intermediate results in registers.
+
+Note that when Bob says "intermediate results" above, he does not really
+mean that, he means "intermediate results stored in registers". We have
+always recognized that intermediate results stored in registers may
+exceed the base range, so why be astonished when this happens!
+
+I will say it again, on a machine like the SPARC, I think it is a very
+bad decision to have only one 32-bit base type. I think it leads to
+all sorts of problems, and makes compatibility with existing Ada 83
+legacy programs impossible.
+
+We briefly went down the route of letting object sizes be dictated by
+the strange Ada 95 small subtype sizes (e.g. natural'size being 31 instead
+of 32), but we 	quickly retracted this (inventing Object_SIze at the same
+time) because it caused major chaos for our users (not to mention for some
+of our own code).
+
+The idea of subtypes by default having a different memory representation
+from their parent types is fundamentally a bad approach.
+
+The idea of letting compilers freely choose whether or not to follow this
+approach in an implementation dependent manner is even worse.
+
+The lack of a feature to control what the compiler chooses here makes the
+problem still worse.
+
+At least in GNAT, you can use Object_Size to tell the compiler what to do.
+For example, if you absolutely need compatibility with an Ada compiler that
+does behave in the manner that Bob envisions (object sizes for subtypes
+by default being smaller than object sizes for the parent type), then you
+can force this in GNAT with Object_Size attribute definition clauses (which
+are allowed on subtypes). We have never had a customer that we know of who
+had this requirement.
+
+I have said it before, I will say it again. The Size stuff in Ada 95 is
+badly messed up.
+
+In Ada 83, it was insufficiently well defined, but it permitted compilers
+to behave reasonably.
+
+In Ada 95, it was specifically defined with respect to type sizes, in a
+manner that was incompatible with most Ada 83 compilers and which causes
+a lot of problems. 
+
+Ada 95 copied Ada 83 in not providing a way to specify default object
+sizes, but the problem is suddenly much worse in Ada 95. This is because
+in Ada 83, the assumption was that object sizes correspond to type sizes
+in general, which is reasonable. But you CANNOT do this in Ada 95, because
+the types sizes are strange.
+
+Very annoying!
+
+****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Monday, April 13, 1998 1:22 PM
+To: 	arg95@sw-eng.falls-church.va.us
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+The goal of this AI is to minimize implementation dependence
+in the area of scalar type stream representation.
+
+I see two choices:
+
+   1) Try to minimize implementation dependence in the area
+      of base range selection, and retain the tie between
+      base range and stream representation;
+
+   2) Separate the selection of base range from the selection
+      of stream representation, and tie stream representation
+      to the properties of the first subtype.
+
+Choosing (1) above means specifying the algorithm for choosing
+the base range in terms of the first subtype size relative to the size 
+of the storage element, the word size, etc.  
+
+Choosing (2) means specifying the algorithm for choosing the
+stream representation in terms of the first subtype size relative to
+the size of the stream element (and perhaps taking the
+size of the storage element and or the size of the word into acount).
+
+If we were to choose (2), I would hope implementations that already
+choose "minimal" size base ranges would have no need to change.
+So choosing (2) would simply affect implementations which happen
+to choose bigger base ranges today.
+
+Choosing (1) would similarly only affect implementations that currently
+have bigger base ranges, and would presumably have the identical
+affect on users of streams, but would also affect existing users
+of 'Base (which might be considered a bug or a feature).
+
+Any comments on choice (1) vs. choice (2)?
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Monday, April 13, 1998 5:39 PM
+To: 	stt@inmet.com
+Cc: 	arg95@sw-eng.falls-church.va.us
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+> Any comments on choice (1) vs. choice (2)?
+
+I favor choice 2.  One reason, which I stated in my previous message, is
+that I would like the following idiom to be efficient:
+
+    type Dummy is range 1..10_000;
+    type Count is range Dummy'Base range 1..Dummy'Base'Last;
+
+I would like to hear from other ARG members (eg things like, "Yeah, we
+agree", or "No, that's a bogus/useless idiom", or "the above should be
+INefficient", or whatever).
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Tuesday, April 14, 1998 5:22 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<>    1) Try to minimize implementation dependence in the area
+>       of base range selection, and retain the tie between
+>       base range and stream representation;
+>
+>    2) Separate the selection of base range from the selection
+>       of stream representation, and tie stream representation
+>       to the properties of the first subtype.
+>>
+
+Just so things are clear, I agree that 1) is impractical at this stage,
+although it is a pity that there is so much implementation dependence
+here. For interest what do other compilers do between the two following
+choices on e.g. the SPARC:
+
+  1) Multiple integer base types, 8,16,32 bits
+  2) Single integer base type 32 bits
+
+(just ignore the presence of absence of a 64-bit integer type for this
+purpose).
+
+I underdstand the answers to be:
+
+  GNAT: 1)
+  Intermetrics: 2)
+
+But what do other compilers do?
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Tuesday, April 14, 1998 5:07 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<I favor choice 2.  One reason, which I stated in my previous message, is
+that I would like the following idiom to be efficient:
+
+    type Dummy is range 1..10_000;
+    type Count is range Dummy'Base range 1..Dummy'Base'Last;
+
+I would like to hear from other ARG members (eg things like, "Yeah, we
+agree", or "No, that's a bogus/useless idiom", or "the above should be
+INefficient", or whatever).
+>>
+
+I see this particular choice of the idiom as strange, since you still
+have a range on type Count, so you will save nothing in a decent compiler.
+Intermediate results for type Dummy and Count are the same, because
+the base is the same, and you get range checks anyway, because it is
+not full range. Yes, OK, there are a few cases in which only the upper
+bound is checked which can be eliminated.
+
+A much more usual use of this idiom is when the range is entirely omitted
+from the second declaration, and this is indeed useful.
+
+However, a much more usual kind of use of this idiom is:
+
+    type Dummy is range - (2 ** 31 - 1) .. + (2 ** 31 - 1);
+    type Efficient is new Dummy'Base;
+
+where you are clearly aiming at about a 32-bit type (allowing for 1's comp
+and also asking for 36 bits on a 36 bit machine).
+
+We used to do this in the GNAT sources, but these days, it's of academic
+interest anyway, since all interesting machines are 2's complement, and
+all interesting machines have 32 bit integers.
+
+I would expect Bob Duff's particular set of declarations to be aiming at
+an efficient 16-bit type if anything, although after learning of the 
+peculiar choice of some compilers to fail to provide a 16-bit base type
+on machines where I would have expected it to be present (e.g. SPARC), it
+is clear that this is a highly non-portable idiom.
+
+As such, I don't think we want to take this idiom (in the form Bob presents
+it which is clearly non-portable) too much into effect, since any use of this
+will be highly implementation dependent (and worse, you can't even clearly
+tell what the programmer had in mind from looking at the text).
+
+It is a pity that the RM gives no guidance here, but we are clearly stuck
+with a situation where different compilers do VERY different things here.
+
+Probably we have no choice but to kludge the Stream_IO stuff at this stage,
+since it would probably be disruptive for the compiler that chooses large
+base types to change.
+
+What we have here in my mind is a situation where, especially given the
+rules regarding stream types that are clear in the RM, a compiler has made
+a bad choice of how to do things (Bob, I know that you think the choice is
+good from other points of view, but you have to agree that *given the rules
+in the RM for stream handling*, this choice is *not* the right one overall).
+
+Given this unfortunate choice, the compiler comes along to the ARG and
+petitions for a change in the language. OK, at this stage I think we have
+to grant the petition.,
+
+But I hope that makes my uneasiness about the precedent we are setting clear.
+
+
+We have a situation where there are two implementation choices that are
+consistent with the RM. One leads to clearly unfortunate choices for the
+behavior of streams, one does things just fine. Normally if there are two
+implementation choices consistent with the RM, and one works and one does
+not, we expect the RM to be dictating the choice. We don't expect the choice
+to dictate changes to the RM.
+
+Still, as I note above, I think the only reasonable choice here is to
+make the change to the RM. It has no effect on compilers that choose
+base types to match storage modes rather than register modes (i.e. that
+treat integer the same as floating-point), and it allows compilers that
+choose base types for the integer case to match register modes to avoid
+a clearly undesirable effect for stream behavior.
+
+****************************************************************
+
+From: 	Pascal Leroy[SMTP:phl@Rational.Com]
+Sent: 	Tuesday, April 14, 1998 5:45 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+>    1) Try to minimize implementation dependence in the area
+>       of base range selection, and retain the tie between
+>       base range and stream representation;
+>
+>    2) Separate the selection of base range from the selection
+>       of stream representation, and tie stream representation
+>       to the properties of the first subtype.
+
+Option (1) would obviously impact programs which use 'Base and programs which
+have 'large' intermediate results.  While we know that such programs are
+essentially non-portable, requiring their behavior to change seems like a very
+bad idea to me.
+
+I vote for (2).
+
+Pascal
+
+****************************************************************
+From: 	Jean-Pierre Rosen[SMTP:rosen.adalog@wanadoo.fr]
+Sent: 	Tuesday, April 14, 1998 1:39 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+>The goal of this AI is to minimize implementation dependence
+>in the area of scalar type stream representation.
+>
+>I see two choices:
+>
+>   1) Try to minimize implementation dependence in the area
+>      of base range selection, and retain the tie between
+>      base range and stream representation;
+>
+>   2) Separate the selection of base range from the selection
+>      of stream representation, and tie stream representation
+>      to the properties of the first subtype.
+
+1) may potientially affect all programs, while 2) affects only those that use streams.
+I would therefore argue for 2) on the basis that it is much less disruptive.
+----------------------------------------------------------------------------
+                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
+
+****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Tuesday, April 14, 1998 9:06 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+> ...
+> Just so things are clear, I agree that 1) is impractical at this stage,
+> although it is a pity that there is so much implementation dependence
+> here. For interest what do other compilers do between the two following
+> choices on e.g. the SPARC:
+> 
+>   1) Multiple integer base types, 8,16,32 bits
+>   2) Single integer base type 32 bits
+> 
+> (just ignore the presence of absence of a 64-bit integer type for this
+> purpose).
+> 
+> I underdstand the answers to be:
+> 
+>   GNAT: 1)
+>   Intermetrics: 2)
+> 
+> But what do other compilers do?
+
+The Intermetrics front end is happy to support either choice for 
+base types.  I believe Aonix and Green Hills both chose to have 
+only 32-bit base types.
+
+The Raytheon "Patriot" compiler has only one 24-bit base integer
+types, for what that's worth ;-).
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Tuesday, April 14, 1998 8:55 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+I suspect that what we *should* have done in Ada 9X is to make stream
+I/O completely portable by default, by specifying some particular
+representation, such as some preexisting standard, like XDR.  I don't
+know anything about XDR, so I don't know if it would have been the
+appropriate choice, but I think it is unfortunate that (1) we didn't
+nail things down precisely enough, (2) we tied stream representations to
+machine-dependent in-memory representations, and (3) we tried to "roll
+our own" instead of relying on some preexisting standard.
+
+I guess it's too late, now.
+
+- Bob
+
+****************************************************************
+
+From: 	Pascal Leroy[SMTP:phl@Rational.Com]
+Sent: 	Tuesday, April 14, 1998 10:40 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+> For interest what do other compilers do between the two following
+> choices on e.g. the SPARC:
+>
+>   1) Multiple integer base types, 8,16,32 bits
+>   2) Single integer base type 32 bits
+>
+> I underdstand the answers to be:
+>
+>   GNAT: 1)
+>   Intermetrics: 2)
+
+We do 2.
+
+Pascal
+
+_____________________________________________________________________
+Pascal Leroy                                    +33.1.30.12.09.68
+pleroy@rational.com                             +33.1.30.12.09.66 FAX
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Tuesday, April 14, 1998 7:31 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<We do 2.
+
+Pascal
+>>
+
+Interesting. Note that the differences will not be that great in practice.
+Certainly simple variables as in
+
+  type x is range 1 .. 100;
+  y,z : x;
+
+  y := z + y;
+
+will generate identical code and allocations in the two cases.
+
+Incidentally, I assume this means that Rational has the same problem with
+excessive size for stream elements ... so that means that two of the main
+technologies really need the fix that is in this AI.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Tuesday, April 14, 1998 7:33 PM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<I suspect that what we *should* have done in Ada 9X is to make stream
+I/O completely portable by default, by specifying some particular
+representation, such as some preexisting standard, like XDR.  I don't
+know anything about XDR, so I don't know if it would have been the
+appropriate choice, but I think it is unfortunate that (1) we didn't
+nail things down precisely enough, (2) we tied stream representations to
+machine-dependent in-memory representations, and (3) we tried to "roll
+our own" instead of relying on some preexisting standard.
+
+I guess it's too late, now.
+>>
+
+GNAT provides XDR as an optional choice, but you would not want it as the
+required default -- too inefficient.
+
+****************************************************************
+
+From: 	David Emery[SMTP:emery@mitre.org]
+Sent: 	Wednesday, April 15, 1998 6:34 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+I forget the name of the encoding scheme that DCE RPC uses, but it's much
+better than XDR, particularly in homogenous networks.  In fact, I argued to 
+Anthony Gargaro that the DS Annex should take a 'minimalist' approach and
+consist of binding methods to RPC and associated data encoding schemes such
+as XDR.   I'm still sorry that the DS Annex didn't provide this simplistic
+functionality, since it's proven to be very useful.
+
+				dave
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Wednesday, April 15, 1998 6:43 AM
+Subject: 	Re: AI-195; Stream representation for scalar types
+
+<<I forget the name of the encoding scheme that DCE RPC uses, but it's much
+better than XDR, particularly in homogenous networks.  In fact, I argued to
+Anthony Gargaro that the DS Annex should take a 'minimalist' approach and
+consist of binding methods to RPC and associated data encoding schemes such
+as XDR.   I'm still sorry that the DS Annex didn't provide this simplistic
+functionality,
+since it's proven to be very useful.
+>>
+
+It's quite trivial in GNAT to provide a plugin replacement unit that 
+specifies what protocol you want. I think this is a design that is
+very attractive (see s-stratt.adb in the GNAT library).
+
+Incidentally we use XDR *precisely* to deal with heterogenous networks. 
+THe default encodings work perfectly well on homogenous networks. I
+suppose one could worry about different compilers being used on a
+homogenous network, but that seems somewhat theoretical so far.
+
+I do hope that if any other compilers implement annex E that they follow
+the GNAT design of isolating the low level encodings in a separate
+easily modifiable module. This really seems the right solution, rather
+than trying to pin down any one method as appropriate (now or when the
+standard was being designed).
+
+****************************************************************
+
+From: 	Anthony Gargaro[SMTP:abg@SEI.CMU.EDU]
+Sent: 	Wednesday, April 15, 1998 7:43 AM
+Subject: 	Re: AI-195; Stream representation for scalar types 
+
+Dear David-
+
+>I forget the name of the encoding scheme that DCE RPC uses, but it's much
+>better than XDR, particularly in homogenous networks.  
+
+It is called Network Data Representation (NDR) transfer syntax (refer
+X/Open DCE: Remote Procedure Call, Chapter 14) and is the default transfer
+syntax for heterogeneous networks.
+
+>In fact, I argued to
+>Anthony Gargaro that the DS Annex should take a 'minimalist' approach and
+>consist of binding methods to RPC and associated data encoding schemes such
+>as XDR.   I'm still sorry that the DS Annex didn't provide this simplistic
+>functionality,
+>since it's proven to be very useful.
+
+I believe the approach taken in Annex E was (and is) correct. A binding
+to DCE RPC would have been a significant undertaking and from my recent
+experience using DCE a dubious investment by the design team since it is
+relatively straightforward to use the specified C APIs from within an
+Ada partition.
+
+It is interesting to note that the P1003.21 (Realtime Distributed Systems
+Communication) group has been trying to reach consensus on a suitable binding
+for heterogeneous data transfer for some considerable time.
+
+Anthony.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent