CVS difference for ais/ai-00340.txt

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

--- ais/ai-00340.txt	2003/08/01 01:40:09	1.1
+++ ais/ai-00340.txt	2003/09/30 02:01:13	1.2
@@ -577,3 +577,188 @@
 has just one).
 
 ****************************************************************
+
+From: John Barnes
+Sent: Monday, September 29, 2003  6:45 AM
+
+Here are some comments on the recent proposals on ... the reduce attribute from
+one of my colleagues.
+
+-------------------------------------------------
+
+Most computers have both an Add instruction and a Subtract
+instruction (although logically you only need Subtract).
+
+Most but not all computers have an "immediate" address
+mode, where you take one of the operands of the Add or
+Subtract, provided it is a constant, from the address
+field of the instruction, rather than from a register
+or from the memory pointed to by the address field.
+
+This has always struck me as a little odd, because,
+say, for 16-bit numbers, you can add any constant
+between -32768 and +32767 with an Add instruction,
+and you can ADD any constant between +32768 and -32767
+with a subtract instruction. What a waste!
+
+I've always thought that it would be more useful if
+Add-immediate added a number between 0 and +65535,
+and subtract-immediate added a number in 0 to -65535,
+(setting the carry & overflow flags appropriately).
+This is perfectly meaningful even for SIGNED numbers.
+
+Turning now from machines to high-level languages,
+I should, for example, be able to add, say, +64000
+to a signed 16-bit signed integer which happens to be
+in -32768..-31233 (and get an exception otherwise).
+
+This should apply even if the hardware does not
+support it. The compiler simply has to generate
+two add or subtract instructions, (or perhaps just
+one instruction: add -1536 in the above example, and
+interpret the carry & overflow flags differently?)
+
+A similar problem arose in Ada83 when writing a package
+to manipulate angles in "BAMS", where the requirement
+is to "wrap round" without overflow, as in
+   Track := Cyclic (Heading + Drift);
+
+   function "+" (LEFT, RIGHT: WORD) return WORD_ADD is begin
+      return (LEFT, RIGHT); -- A record.
+   end "+";
+
+   function Cyclic (ITEM: WORD_ADD) return WORD is begin
+      if ITEM.LEFT >= 0 and then ITEM.RIGHT >= 0
+      and then ITEM.LEFT + WORD'FIRST + ITEM.RIGHT >= 0 then
+         return ITEM.LEFT + WORD'FIRST + ITEM.RIGHT + WORD'FIRST;
+      elsif ITEM.LEFT < 0 and then ITEM.RIGHT < 0
+      and then ITEM.LEFT - WORD'FIRST + ITEM.RIGHT < 0 then
+         return ITEM.LEFT - WORD'FIRST + ITEM.RIGHT - WORD'FIRST;
+      end if;
+      return ITEM.LEFT + ITEM.RIGHT;
+   end Cyclic;
+
+Here, in the tests, I want to add +32768, which I can
+just do, by adding -(-32768), written more sensibly as
+-'FIRST. (In the return statements, I want to add +65536,
+but this has to be split anyway, to avoid overflow).
+
+Of course, in Ada95 I can use modular types for BAMS,
+provided I view angles as in 0..360 rather than
+-180..+180, and I get the wrap-round for free.
+
+But the problem posed by this AI in Ada95 is similar to
+the BAMS problem in Ada83 and can be solved by similar code.
+
+An argument based on "writing a simulator" is dangerous.
+(I wrote a simulator for my Elliott 900, in Ada, before the
+1983 standard was published. It's on the Internet
+somewhere.)
+Many machines have a multiply instruction which returns
+a product twice as long as the longest add instruction,
+and hence probably twice as long as the longest Ada type.
+
+Making this product visible would certainly make writing
+simulators easier, especially writing a simulator for a
+machine on to run on the same machine. (And if this
+product were made visible to the Ada programmer,
+we could dispense with fixed-point arithmetic!)
+And cyclic shifts, and bit-count, and bit-reverse...?
+
+So I think we have a slippery slope here.
+The AI poses a problem no worse than many others.
+If we are going to fix it, we probably should fix the
+"add 64000" problem, and should probably consider other
+problems associated with mixed-mode arithmetic too.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, September 29, 2003  7:45 AM
+
+For what it is worth, I think the "'Reduce" attribute
+is a good idea.  I understand the point being made
+that there are other similar problems in other places
+that we aren't fixing, but this particular one comes
+up very often when using modular types.  It is natural
+to think that conversion might already do this automatically,
+but that violated a fairly basic assumption that conversions
+are generally reversible (which is important for
+"view" conversions), in the absence of a Constraint_Error.
+[Of course conversion from float to integer bends this
+rule, but that's the old "exception that proves the
+rule" I suppose.]
+
+In any case, by adding an attribute to do what conversion
+might otherwise do, we might actually reduce (;-) confusion, or
+at least misconceptions, about the conversion.  We would also
+make it easier to use modular and signed integer types together,
+something which today is not so pleasant.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Monday, September 29, 2003  11:39 AM
+
+I'm with Tucker here.  I'll just add that some of the painful cases involve
+numeric literals at compile time.  For example, I recently found myself needing
+to write:
+
+   type Modular is ...;
+   X: Modular;
+   Residue: constant := 16#FFFF_FFFF_FFFF_FFFF# mod Modular'Modulus;
+   ...
+   X := X + Residue;
+
+Now of course the interesting case to me was when Residue was small and
+non-zero.  But I had to go through the (potentially error-prone) process of
+writing a constant of type _universal_integer_ just to get the number I needed.
+
+   X := X + Modular'Reduce(16#FFFF_FFFF_FFFF_FFFF#);
+
+Should generate the same code and do away with the magic. Note that there may
+be no run-time type that can be used to represent 16#FFFF_FFFF_FFFF_FFFF# or
+Modular'Modulus, but that is not an issue for the 'Reduce attribute.  Either
+the function can be evaluated at compile time, or it can be converted to a
+divide operation.  Of course, the magic of the reduce attribute comes when it
+can be replaced by nothing or by a change of sign at compile time:
+
+    Y: Integer;
+    ...
+    X := X + Reduce(-Y); -- not that a user would write this...
+
+    Can be converted to a type conversion--but not the Ada defined type
+    conversion--and then subtracting the result from X.
+
+So adding this attribute should not involve any code generator changes, but
+simplifies the process of writing code in some problem cases.  Note that this
+particular case, as I said, is one that really takes a language lawyer to write
+the code correctly without the attribute, and is easy for anyone with 'Reduce.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, September 29, 2003  6:35 PM
+
+> Should generate the same code and do away with the magic. Note
+> that there may be no run-time type that can be used to represent
+> 16#FFFF_FFFF_FFFF_FFFF# or Modular'Modulus, but that is not an
+> issue for the 'Reduce attribute.
+
+This assumes that 'Modulus is known at compile-time, which isn't true in
+code-shared generic bodies.
+
+...
+> So adding this attribute should not involve any code generator
+> changes, but simplifies the process of writing code in some
+> problem cases.  Note that this particular case, as I said, is one
+> that really takes a language lawyer to write the code correctly
+> without the attribute, and is easy for anyone with 'Reduce.
+
+But this is still true; the implementation already has some way to handle
+dynamic 'modulus values if it implements shared generics for modular types.
+
+So I'm in favor of the attribute as well. I've run into cases where getting it
+right is a real pain, and 'Reduce would have eliminated the pain.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent