Re: Help with Atomic_Components and whole array assignment

["Nick Roberts" <nickroberts@callnetuk.com>]

If it's any consolation Tuck, my interpretation of Volatile (nothing to do
with Atomic) would always have been (and still is) that:

   for i in A'Range loop
      A(i) := 0;
   end loop;

where Volatile (or Volatile_Components) applied to A, would generate
A'Length separate copies into memory, in whatever machine code it was.

My interpretation of Atomic would be simply to avoid generating code that
might bugger up multi-task access to the object Atomicked (or its components
if Atomic_Componented). Of course, Atomic shoves in a dose of Volatile
automatically, and quite right too.

I propose a representation attribute, Storage_Operations, of type
System.Storage_Operations.Operation_Profile, which is an array of Boolean
indexed on an enumerated type System.Storage_Operations.Operation_Mode,
which would have a value for every (relevant) kind of basic memory access
the compiler could generate. E.g.:

   package System.Storage_Operations is
      type Operation_Mode is (Read_8, Read_16, Read_32, Write_8, Write_16,
Write_32);
      type Operation_Profile is array (Access_Mode) of Boolean;
   end;

   A: array (...) of ...;
   for A'Storage_Operations use (Read_8, Write_8);

This attribute could be used in a representation clause to specify precisely
which kinds of memory access are allowed for an object or type. Perhaps its
use should imply or require Volatile. It would, of course, be fairly
machine-dependent, but that's unavoidable. It would often allow the
avoidance of assembly; in some situations this could be very valuable.

We could have a package e.g.:

   with Interfaces;
   package System.Port_Access is
      type Port_8_Address is mod 2**16;
      type Port_8_Element is new Interfaces.Unsigned_8;
      type Port_16_Address is mod 2**16;
      type Port_16_Element is new Interfaces.Unsigned_16;
      generic
         type Index_Type is (<>);
      package Arrays_Of is
         type Port_8_Array is array (Index_Type range <>) of Port_8_Element;
         type Port_16_Array is array (Index_Type range <>) of
Port_16_Element;
      end;
      -- also provide for offsets, arithmetic, etc.
   end;

and then:

   Flags: System.Port_Access.Port_16_Element;
   for Flags'Port_Address use 16#012E#;

   subtype Data_Port is Integer range 0..3;
   package Data_IO is System.Port_Access.Arrays_Of(Data_Port)
   Data: Data_IO.Port_8_Array(Data_Port);
   subtype Data_Area is System.Port_Access.Port_8_Address range
16#0120#..16#0123#;
   for Data'Port_Address use Data_Area;

This would often allow assembly to be avoided for port access. Better and
better, eh?

Finally, if I were writing a device driver, in any language, I would want to
look at the machine code produced - very carefully, in places - regardless
of whether it seemed to work or not, just to see what it was really doing.
(But then I'm paranoid like that ;-)

PS: I'm making proposals with the aim of putting them into an actual
compiler which will be used in a specific situation (which involves lots of
device drivers). Helpful criticism or better proposals welcome!

--
Nick Roberts
http://www.AdaOS.org