volatile vs aliased

volatile vs aliased

[REH]

I'm converting some code written for Gnat to compile with Apex.  The
software has bindings to C functions (OS calls).  Some of these take
System.Address as parameters.  Apex complains about the variables used
in these calls (via 'Address) because they not volatile or aliased (or
imported, exported, etc.).  My question is: which should I use?  Is
there any difference whether a variable is volatile or aliased?

I am assuming the compiler is concerned about the variable possibly
being changed in the call (which, of course, is true).  Is there a way
to satisfy the compiler without stopping optimizations of the variable
after the call, or do I need to use a second variable to do this?

Re: volatile vs aliased

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:
> I'm converting some code written for Gnat to compile with Apex.  The
> software has bindings to C functions (OS calls).  Some of these take
> System.Address as parameters.  Apex complains about the variables used
> in these calls (via 'Address) because they not volatile or aliased (or
> imported, exported, etc.).  My question is: which should I use?  Is
> there any difference whether a variable is volatile or aliased?
>
> I am assuming the compiler is concerned about the variable possibly
> being changed in the call (which, of course, is true).  Is there a way
> to satisfy the compiler without stopping optimizations of the variable
> after the call, or do I need to use a second variable to do this?

I like this warning given by Apex; I think it would be nice if GNAT
would also warn in this situation.

pragma Volatile (Variable) says the compiler must not optimise away
any reads or writes to that variable, and that it may not add extra
reads or writes beyond those you explicitly request in your program
text.  You want to use that for hardware registers, where a "read"
operation may have a side effect such as changing the device's state.

Whenever you access a variable through an address value, the variable
is aliased, so you should say that explicitly.  Otherwise, the
compiler may be tempted to place the variable in a processor register,
which has no address.

In addition, pragma Import (Ada, Variable) says that the compiler may
not insert default initialisations for that variable, or assume
anything about the value of the variable, before you write to it.  But
the compiler may do optimisations, because it is allowed to assume
that no side effects occur when you read from or write to the variable
(that is, side effects not explicitly requested from the program
text).  In your situation, it seems that you want something like this
(which, incidentally, I use very often):

type T is ...;

procedure Read_Variable (At_Address : in  System.Address;
                         Into       : out T) is
   V : aliased T;
   -- suppress default initialisation, I know what I'm doing.
   pragma Import (Ada, V);
   for V'Address use At_Address;
begin
   -- perform my own explicit validation of the variable, perhaps
   -- using 'Valid; then, copy into Into:
   Into := V;
end Read_Variable;

-- 
Ludovic Brenta.

Re: volatile vs aliased

[REH]

Ludovic Brenta wrote:
> I like this warning given by Apex; I think it would be nice if GNAT
> would also warn in this situation.
>
> pragma Volatile (Variable) says the compiler must not optimise away
> any reads or writes to that variable, and that it may not add extra
> reads or writes beyond those you explicitly request in your program
> text.  You want to use that for hardware registers, where a "read"
> operation may have a side effect such as changing the device's state.
>
> Whenever you access a variable through an address value, the variable
> is aliased, so you should say that explicitly.  Otherwise, the
> compiler may be tempted to place the variable in a processor register,
> which has no address.
>
> In addition, pragma Import (Ada, Variable) says that the compiler may
> not insert default initialisations for that variable, or assume
> anything about the value of the variable, before you write to it.  But
> the compiler may do optimisations, because it is allowed to assume
> that no side effects occur when you read from or write to the variable
> (that is, side effects not explicitly requested from the program
> text).  In your situation, it seems that you want something like this
> (which, incidentally, I use very often):
>
> type T is ...;
>
> procedure Read_Variable (At_Address : in  System.Address;
>                          Into       : out T) is
>    V : aliased T;
>    -- suppress default initialisation, I know what I'm doing.
>    pragma Import (Ada, V);
>    for V'Address use At_Address;
> begin
>    -- perform my own explicit validation of the variable, perhaps
>    -- using 'Valid; then, copy into Into:
>    Into := V;
> end Read_Variable;
>
> --
> Ludovic Brenta.

VERY helpful!  Thank you so much.

I'm dealing with a situation where I have to do symbol table lookups
from the OS which return an address to procedure or function.  This is
done in several places in the code.  The reason is I have to support
different hardware dynamically.  For example, if I am on board A, I
call Foo.  The comparible subprogram on B is Bar.  So, I cannot just
make pragma exports for them both as one will be undefined.  Anyways,
to make it easier, I wanted to make a generic which just returned an
access type without having to do the pragma Import and for X'address in
every case.  Then calling the subprogram is simple.  My first pass is:

  generic
    type Data_Type is private;
    type Data_Ptr is access all Data_Type;
  function Address_To_Access(Addr : System.Address) return Data_Ptr;

  function Address_To_Access(Addr : System.Address) return Data_Ptr is
  begin
    if Addr = System.Null_Address then
      return null;
    else
      declare
        Data: aliased Data_Type;
        for Data'Address use Addr;
      begin
        return Data'Unchecked_Access;
      end;
    end if;
  end Address_To_Access;


Two questions:
1) Is this even a smart thing to do?
2) How would I define a generic like the above for an subprogram with
an unknown signature?

Thanks again for the help.

REH

Re: volatile vs aliased

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:
> VERY helpful!  Thank you so much.
>
> I'm dealing with a situation where I have to do symbol table lookups
> from the OS which return an address to procedure or function.  This is
> done in several places in the code.  The reason is I have to support
> different hardware dynamically.  For example, if I am on board A, I
> call Foo.  The comparible subprogram on B is Bar.  So, I cannot just
> make pragma exports for them both as one will be undefined.  Anyways,
> to make it easier, I wanted to make a generic which just returned an
> access type without having to do the pragma Import and for X'address in
> every case.  Then calling the subprogram is simple.  My first pass is:
>
>   generic
>     type Data_Type is private;
>     type Data_Ptr is access all Data_Type;
>   function Address_To_Access(Addr : System.Address) return Data_Ptr;
>
>   function Address_To_Access(Addr : System.Address) return Data_Ptr is
>   begin
>     if Addr = System.Null_Address then
>       return null;
>     else
>       declare
>         Data: aliased Data_Type;
>         for Data'Address use Addr;
>       begin
>         return Data'Unchecked_Access;
>       end;
>     end if;
>   end Address_To_Access;
>
>
> Two questions:
> 1) Is this even a smart thing to do?

Why do you have to use a generic?  Why not just:

procedure Call_Procedure (At_Address : in System.Address) is
   procedure Proc;
   for Proc'Address use At_Address;
begin
   Proc;
end Call_Procedure;

The above effectively converts from an address to an
access-to-procedure, and calls the procedure.  If what you want is
convert from an address to an access-to-data, you should probably use
Ada.Address_To_Access_Conversions.

> 2) How would I define a generic like the above for an subprogram with
> an unknown signature?

I don't know how you could call a procedure with unknown parameters.
Or perhaps you mean with one known parameter which is the address of
a record containing arbitrary parameters?

generic
   type Parameter_Type is limited private; -- [1]
procedure Call_Procedure (At_Address : in System.Address;
                          Params     : in Parameter_Type);

procedure Call_Procedure (At_Address : in System.Address;
                          Params     : in Parameter_Type) is
   procedure Proc (Params : in System.Address);
   for Proc'Address use At_Address;
begin
   Proc (Params'Address);
end Call_Procedure;

Is this close to what you want?

[1] I think the type has to be declared limited, so that it is always
passed by reference to Call_Procedure.  This guarantees that the
parameter has an address, and is not in a register.  I have not
compiled or tried this code, so please take it with due care.

-- 
Ludovic Brenta.

Re: volatile vs aliased

[REH]

Ludovic Brenta wrote:
> Why do you have to use a generic?  Why not just:
>
> procedure Call_Procedure (At_Address : in System.Address) is
>    procedure Proc;
>    for Proc'Address use At_Address;
> begin
>    Proc;
> end Call_Procedure;

I was just trying to by lazy, and not do that everytime.  If I have to,
I have to.

>
> I don't know how you could call a procedure with unknown parameters.
> Or perhaps you mean with one known parameter which is the address of
> a record containing arbitrary parameters?
The caller would know.  What I don't know to do (and probably can't) is
define a generic that can be instantiated using *any* access type, even
one to a subprogram.

I guess I am spending more time trying to avoid work, than just doing
it.

REH

Re: volatile vs aliased

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:
> Ludovic Brenta wrote:
>> Why do you have to use a generic?  Why not just:
>>
>> procedure Call_Procedure (At_Address : in System.Address) is
>>    procedure Proc;
>>    for Proc'Address use At_Address;
>> begin
>>    Proc;
>> end Call_Procedure;
>
> I was just trying to by lazy, and not do that everytime.  If I have to,
> I have to.

I don't understand.  Do you mean to say that one Call_Procedure is not
sufficient?  That you'd have to have many such procedures?  Why?

>> I don't know how you could call a procedure with unknown parameters.
>> Or perhaps you mean with one known parameter which is the address of
>> a record containing arbitrary parameters?
> The caller would know.  What I don't know to do (and probably can't) is
> define a generic that can be instantiated using *any* access type, even
> one to a subprogram.
>
> I guess I am spending more time trying to avoid work, than just doing
> it.

In my example, the Parameter_Type can contain an access-to-subprogram.
Of course, you need to instantiate the generic once per parameter
profile, and there may be many different ones, so that the generic
doesn't really save you much work.

-- 
Ludovic Brenta.

Re: volatile vs aliased

[REH]

Ludovic Brenta wrote:
> I don't understand.  Do you mean to say that one Call_Procedure is not
> sufficient?  That you'd have to have many such procedures?  Why?
I've not sure if you are asking if I need several procedures per
address (I do not) or why I have many address (I do).  Either way, your
way is probably best:  just make one wrapper procedure for each
address.  I was "creating" the procedure from the address at each call
point.  Sigh.  Sometimes the simplest answer eludes me.

Thanks for the great advice.
 REH

Re: volatile vs aliased

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:

> Ludovic Brenta wrote:
>> I don't understand.  Do you mean to say that one Call_Procedure is not
>> sufficient?  That you'd have to have many such procedures?  Why?
> I've not sure if you are asking if I need several procedures per
> address (I do not) or why I have many address (I do).  Either way, your
> way is probably best:  just make one wrapper procedure for each
> address.  I was "creating" the procedure from the address at each call
> point.  Sigh.  Sometimes the simplest answer eludes me.

Even simpler: you need just one wrapper per parameter profile,
i.e. one wrapper for all parameterless procedures, etc.

-- 
Ludovic Brenta.

Re: volatile vs aliased

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> procedure Call_Procedure (At_Address : in System.Address) is
>    procedure Proc;
>    for Proc'Address use At_Address;
> begin
>    Proc;
> end Call_Procedure;

With GCC 4.0.0, you need to say

   pragma Import (C, Proc);

as well.

   with Ada.Text_IO; use Ada.Text_IO;With System;
   procedure Acc is
      procedure Call (At_Address : System.Address) is
         procedure Proc;
         pragma Import (C, Proc);
         for Proc'Address use At_Address;
      begin
         Proc;
      end Call;
      procedure Callee is
      begin
         Put_Line ("hello world.");
      end Callee;
   begin
      Call (Callee'Address);
   end Acc;

Re: volatile vs aliased

[Jeffrey R. Carter]

Ludovic Brenta wrote:

>    type Parameter_Type is limited private; -- [1]

I'd probably use unknown discriminants (<>) here, since you don't create any 
objects of the type.

> [1] I think the type has to be declared limited, so that it is always
> passed by reference to Call_Procedure.  This guarantees that the
> parameter has an address, and is not in a register.  I have not
> compiled or tried this code, so please take it with due care.

For a generic formal type, limited only means that the generic cannot use ":=", 
"=", or "/=" for the type. The pass-by-reference limited-ness depends on the 
full type definition of the actual; nothing prevents the actual for 
Parameter_Type from being an elementary type, which are pass-by-copy. I don't 
know of any way to ensure that a generic formal type is pass-by-reference except 
to make it tagged.

-- 
Jeff Carter
"I soiled my armor, I was so scared."
Monty Python & the Holy Grail
71

Re: volatile vs aliased

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message
news:87mzlnomca.fsf@ludovic-brenta.org...
...
>  In your situation, it seems that you want something like this
> (which, incidentally, I use very often):
>
> type T is ...;
>
> procedure Read_Variable (At_Address : in  System.Address;
>                          Into       : out T) is
>    V : aliased T;
>    -- suppress default initialisation, I know what I'm doing.
>    pragma Import (Ada, V);
>    for V'Address use At_Address;
> begin
>    -- perform my own explicit validation of the variable, perhaps
>    -- using 'Valid; then, copy into Into:
>    Into := V;
> end Read_Variable;

This seems like a good time to mention that I think the explicit use of
System.Address in Ada 95 and Ada 200Y code is usually a mistake. Since
pragma Convention can be used to ensure that general access types have the
appropriate representation, its rare that Address needs to be used for
interfacing. (There is only a handful of uses of Address in Claw, for
example.)

Moreover, when you *do* need to use it, Address_to_Access_Conversions is the
best way to convert it, not an overlay (which at best blocks optimizations
and at worst won't even work right).

type T is ...;

procedure Read_Variable (At_Address : in  System.Address;
                         Into       : out T) is
   package AAC is new System.Address_to_Access_Conversions (T);
   V : AAC.Object_Pointer := AAC.To_Pointer (At_Address);
begin
    -- perform my own explicit validation of the pointer's contents, perhaps
    -- using 'Valid; then, copy into Into:
    Into := V.all;
end Read_Variable;

But it is better still to declare an appropriate type and never use Address
in the first place:

type Pointer_T is access all T;
pragma Convention (C, Pointer_T);

Address clauses should be restricted to mapping to hardware, IMHO.

                          Randy.

Re: volatile vs aliased

[tmoran]

> its rare that Address needs to be used for interfacing.  (There is only
> a handful of uses of Address in Claw, for example.)
All in one package, where one procedure needs a System.Address parameter.

Re: volatile vs aliased

[REH]

Randy Brukardt wrote:
> This seems like a good time to mention that I think the explicit use of
> System.Address in Ada 95 and Ada 200Y code is usually a mistake. Since
> pragma Convention can be used to ensure that general access types have the
> appropriate representation, its rare that Address needs to be used for
> interfacing. (There is only a handful of uses of Address in Claw, for
> example.)
>
> Moreover, when you *do* need to use it, Address_to_Access_Conversions is the
> best way to convert it, not an overlay (which at best blocks optimizations
> and at worst won't even work right).
>
> type T is ...;
>
> procedure Read_Variable (At_Address : in  System.Address;
>                          Into       : out T) is
>    package AAC is new System.Address_to_Access_Conversions (T);
>    V : AAC.Object_Pointer := AAC.To_Pointer (At_Address);
> begin
>     -- perform my own explicit validation of the pointer's contents, perhaps
>     -- using 'Valid; then, copy into Into:
>     Into := V.all;
> end Read_Variable;
>
> But it is better still to declare an appropriate type and never use Address
> in the first place:
>
> type Pointer_T is access all T;
> pragma Convention (C, Pointer_T);
>
> Address clauses should be restricted to mapping to hardware, IMHO.
>
>                           Randy.
Randy,
That's good stuff.  Will it still apply when the address is to a
subprogram?  Can Address_to_Access_Conversions be instantiated with a
subprogram?  That's what I've been trying to do, but I don't know how
to make a generic that takes an access to an arbitrary subprogram type.
 So, I think I am "stuck" using the for X'address specification.

Thanks,
REH

Re: volatile vs aliased

[Randy Brukardt]

"REH" <spamjunk@stny.rr.com> wrote in message
news:1128606036.713575.3990@z14g2000cwz.googlegroups.com...
...
> That's good stuff.  Will it still apply when the address is to a
> subprogram?  Can Address_to_Access_Conversions be instantiated with a
> subprogram?

No.

>  That's what I've been trying to do, but I don't know how
> to make a generic that takes an access to an arbitrary subprogram type.
>  So, I think I am "stuck" using the for X'address specification.

For that, I generally use an appropriate access-to-subprogram type (with the
correct profile), and a dummy "void" access-to-subprogram, and an
Unchecked_Conversion.

For instance, "void" is cast as a parameterless procedure with the correct
convention. Say we want a access-to-function:

    type Void_Subprogram is access procedure;
    pragma Convention (C, Void_Subprogram);
    -- Use this in the "generic" interfacing routines.

    type A_Func is access function (A : Integer) return Integer;
    pragma Convention (C, A_Func);

    function Convert is new Unchecked_Conversion (Source => Void_Subprogram,
             Target => A_Func);

You do have to know that the C compiler uses the same representation for all
access-to-subprogram types (which is likely, more likely than it is for
Ada), but that's the only assumption that you need to make.

You can also use System.Address in place of Void_Subprogram (using the same
Unchecked_Conversion), but it may not have the appropriate representation on
some targets. (One example was the U2200 compiler we worked on --
access-to-subprogram values included an extra link word along with the
address, so an Unchecked_Conversion from Address wouldn't work. That was
required by the underlying system; I don't think there was a way around it.)

                              Randy.

Re: volatile vs aliased

[Jeffrey R. Carter]

Randy Brukardt wrote:

> This seems like a good time to mention that I think the explicit use of
> System.Address in Ada 95 and Ada 200Y code is usually a mistake. Since
> pragma Convention can be used to ensure that general access types have the
> appropriate representation, its rare that Address needs to be used for
> interfacing. (There is only a handful of uses of Address in Claw, for
> example.)

I'd go further. First, I see if I can use an out or in out parameter of a 
Convention-C non-access type, rather than use a Convention-C access type. Most 
pointer parameters in C exist to get the effect of out or in out parameters, and 
"pragma Import (C, ..." will do the right thing for you without messing with 
access types.

Of course, if the C function has both pointer parameters and returns a value, 
access parameters are the only thing available. Is ease of interfacing to other 
languages another pro for allowing out and in out parameters for functions, 
along with making side effects visible?

-- 
Jeff Carter
"I soiled my armor, I was so scared."
Monty Python & the Holy Grail
71

Re: volatile vs aliased

[Robert A Duff]

"Jeffrey R. Carter" <spam@spam.com> writes:

> Of course, if the C function has both pointer parameters and returns a
> value, access parameters are the only thing available. Is ease of
> interfacing to other languages another pro for allowing out and in out
> parameters for functions, along with making side effects visible?

Yes!  And that argument was brought up during the Ada 9X design.
Apparently, it didn't convince people.

- Bob

Re: volatile vs aliased

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcchdbufnck.fsf@shell01.TheWorld.com...
> "Jeffrey R. Carter" <spam@spam.com> writes:
>
> > Of course, if the C function has both pointer parameters and returns a
> > value, access parameters are the only thing available. Is ease of
> > interfacing to other languages another pro for allowing out and in out
> > parameters for functions, along with making side effects visible?
>
> Yes!  And that argument was brought up during the Ada 9X design.
> Apparently, it didn't convince people.

It also was one of the reasons for making null exclusions explicit in Ada
200Y. In Ada 95, access parameters exclude null automatically, making them
annoying for interfacing when you *do* need to use access values (such as
when null is a legitimate value - can't do that with "in out"). Using a
named access type is required -- but that can bring in accessibility checks
that are irrelevant. (Which is why I don't think I've ever successfully used
'Access on an object, I always have to change to 'Unchecked_Access.)

                           Randy.

Re: volatile vs aliased

[REH]

Randy Brukardt wrote:
> This seems like a good time to mention that I think the explicit use of
> System.Address in Ada 95 and Ada 200Y code is usually a mistake. Since
> pragma Convention can be used to ensure that general access types have the
> appropriate representation, its rare that Address needs to be used for
> interfacing. (There is only a handful of uses of Address in Claw, for
> example.)
>
> Moreover, when you *do* need to use it, Address_to_Access_Conversions is the
> best way to convert it, not an overlay (which at best blocks optimizations
> and at worst won't even work right).
>
> type T is ...;
>
> procedure Read_Variable (At_Address : in  System.Address;
>                          Into       : out T) is
>    package AAC is new System.Address_to_Access_Conversions (T);
>    V : AAC.Object_Pointer := AAC.To_Pointer (At_Address);
> begin
>     -- perform my own explicit validation of the pointer's contents, perhaps
>     -- using 'Valid; then, copy into Into:
>     Into := V.all;
> end Read_Variable;
>
> But it is better still to declare an appropriate type and never use Address
> in the first place:
>
> type Pointer_T is access all T;
> pragma Convention (C, Pointer_T);
>
> Address clauses should be restricted to mapping to hardware, IMHO.
>
>                           Randy.

Can you folks point me to some literature (books, websites, etc.) that
goes into these gory issues (volatile, aliased, convention, import,
export, etc.) in more detail?  I have some great books on Ada, but they
all seem to gloss over these types of issues.  We are in the process of
converting all our Ada code to '95.  It is very low-level and does a
lot of register bit fiddling, OS calls, and such.  I'd like to get more
informed about these new (to me) features that '95 provides.

REH

Re: volatile vs aliased

[Ed Falis]

Ada as a Second Language - Norm Cohen
Concurrency in Ada - Alan Burns & Andy Wellings

Re: volatile vs aliased

[REH]

Ed Falis wrote:
> Ada as a Second Language - Norm Cohen
> Concurrency in Ada - Alan Burns & Andy Wellings

I have "Concurrency in Ada" and I don't see where is spends much time
at all on these issues, though it is an excellent resource.  The Cohen
book has been on my list to bought for awhile now.  I will have to
check it out.

Thanks,

REH

Re: volatile vs aliased

[Robert A Duff]

"REH" <spamjunk@stny.rr.com> writes:

> Can you folks point me to some literature (books, websites, etc.) that
> goes into these gory issues (volatile, aliased, convention, import,
> export, etc.) in more detail?

I'm not sure which text books, if any, cover these issues in detail,
but in any case, you should probably read the relevant parts of the
AARM.  There might also be something in the Rationale about these
things.

- Bob

Re: volatile vs aliased

[Martin Krischik]

Ludovic Brenta wrote:

> pragma Volatile (Variable) says the compiler must not optimise away
> any reads or writes to that variable, and that it may not add extra
> reads or writes beyond those you explicitly request in your program
> text.  You want to use that for hardware registers, where a "read"
> operation may have a side effect such as changing the device's state.

Interesting! So with  pragma Volatile (X) the following two statements are
not the same:

Y := X * X;
Y := X ** 2;

Good to know!

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: volatile vs aliased

[Dmitry A. Kazakov]

On Thu, 06 Oct 2005 10:05:38 +0200, Martin Krischik wrote:

> Ludovic Brenta wrote:
> 
>> pragma Volatile (Variable) says the compiler must not optimise away
>> any reads or writes to that variable, and that it may not add extra
>> reads or writes beyond those you explicitly request in your program
>> text.  You want to use that for hardware registers, where a "read"
>> operation may have a side effect such as changing the device's state.
> 
> Interesting! So with  pragma Volatile (X) the following two statements are
> not the same:
> 
> Y := X * X;
> Y := X ** 2;
>
> Good to know!

BTW, even without Volatile, they are not necessary same!

For intervals X*X /= X**2!

Example:

[-1, 2] * [-1, 2] = [-1, 4]

[-1, 2]**2 = [2, 4]

X**2 is as twice as more accurate than X*X.

To improve accuracy of * and /, arguments need to be analyzed for
dependency. X + X = 2 * X, no matter what.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: volatile vs aliased

[Rolf]

Martin Krischik wrote:
> Ludovic Brenta wrote:
>
> > pragma Volatile (Variable) says the compiler must not optimise away
> > any reads or writes to that variable, and that it may not add extra
> > reads or writes beyond those you explicitly request in your program
> > text.  You want to use that for hardware registers, where a "read"
> > operation may have a side effect such as changing the device's state.
>
> Interesting! So with  pragma Volatile (X) the following two statements are
> not the same:
>
> Y := X * X;
> Y := X ** 2;

Do we have a difference to C/C++ increment operator here? consider

pragma Volatile (x);
x := x + 1;   -- (1)
        vs.
x++;          -- (2)

In the Ada case (1) we are forced to have "read from memory",
"increment" and "write to memory" instructions, whereas in C/C++ (2)
you can get a single "increment memory" instruction (presuming the
mentioned assembler instructions exist on a given processor)

    Rolf

Re: volatile vs aliased

[Björn Persson]

Rolf wrote:
> Do we have a difference to C/C++ increment operator here? consider
> 
> pragma Volatile (x);
> x := x + 1;   -- (1)
>         vs.
> x++;          -- (2)
> 
> In the Ada case (1) we are forced to have "read from memory",
> "increment" and "write to memory" instructions, whereas in C/C++ (2)
> you can get a single "increment memory" instruction (presuming the
> mentioned assembler instructions exist on a given processor)

Are there really memory chips with built-in arithmetic circuitry, so 
that the processor can send an "add one" instruction to the memory and 
have the variable incremented without reading it first? At least I've 
never heard of that. As far as I know, adding and subtracting is the 
processor's job.

And why would you use pragma Volatile on a variable stored in the 
memory, anyway? As Ludovic described it, it would only be useful on 
variables mapped to special hardware devices. I don't think you would 
want to store a counter there.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: volatile vs aliased

[Niklas Holsti]

Bj�rn Persson wrote:

> And why would you use pragma Volatile on a variable stored in the 
> memory, anyway? As Ludovic described it, it would only be useful on 
> variables mapped to special hardware devices. I don't think you would 
> want to store a counter there.

Spin-locks for multiprocessor systems; variables used for 
lock-free task synchronization; other variables directly shared 
between tasks without being enclosed in protected objects (but 
protected by some other synchronization logic, one would hope).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: volatile vs aliased

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Rolf wrote:
>> Do we have a difference to C/C++ increment operator here? consider
>> 
>> pragma Volatile (x);
>> x := x + 1;   -- (1)
>>         vs.
>> x++;          -- (2)
>> 
>> In the Ada case (1) we are forced to have "read from memory",
>> "increment" and "write to memory" instructions, whereas in C/C++ (2)
>> you can get a single "increment memory" instruction (presuming the
>> mentioned assembler instructions exist on a given processor)
> 
> Are there really memory chips with built-in arithmetic circuitry, so
> that the processor can send an "add one" instruction to the memory and
> have the variable incremented without reading it first? At least I've
> never heard of that. As far as I know, adding and subtracting is the
> processor's job.
> 
> And why would you use pragma Volatile on a variable stored in the
> memory, anyway? As Ludovic described it, it would only be useful on
> variables mapped to special hardware devices. I don't think you would
> want to store a counter there.

Or you have a multi tasking application with C interface.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: volatile vs aliased

[Martin Krischik]

Rolf wrote:

> Martin Krischik wrote:
>> Ludovic Brenta wrote:
>>
>> > pragma Volatile (Variable) says the compiler must not optimise away
>> > any reads or writes to that variable, and that it may not add extra
>> > reads or writes beyond those you explicitly request in your program
>> > text.  You want to use that for hardware registers, where a "read"
>> > operation may have a side effect such as changing the device's state.
>>
>> Interesting! So with  pragma Volatile (X) the following two statements
>> are not the same:
>>
>> Y := X * X;
>> Y := X ** 2;
> 
> Do we have a difference to C/C++ increment operator here? consider
> 
> pragma Volatile (x);
> x := x + 1;   -- (1)
>         vs.
> x++;          -- (2)
> 
> In the Ada case (1) we are forced to have "read from memory",
> "increment" and "write to memory" instructions, whereas in C/C++ (2)
> you can get a single "increment memory" instruction (presuming the
> mentioned assembler instructions exist on a given processor)

Well, all machine code I have seen so far only have a INC for registers. And
if you think for it for a sec.: It can't be another way, even if there is a
INC for memory the CPU still has to read the memory increment internally
write back.

The truth is that x++ is a cheat and has allways been. x++ only exists
because it needs less memory to implement then a peep hole optimiser and -
in the light of modern CPU with powerfull MMUs and triple cache - without
any effect anyway.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: volatile vs aliased

[Adrian Knoth]

Martin Krischik <krischik@users.sourceforge.net> wrote:

> The truth is that x++ is a cheat and has allways been. x++ only exists
> because it needs less memory to implement then a peep hole optimiser and -
> in the light of modern CPU with powerfull MMUs and triple cache - without
> any effect anyway.

Triple cache? L1, L2 and what else? Register renaming? Forwarding?


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Wenn einer erst mal umf�llt, steht er nicht mehr gut da.

Re: volatile vs aliased

[Martin Krischik]

Adrian Knoth wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> 
>> The truth is that x++ is a cheat and has allways been. x++ only exists
>> because it needs less memory to implement then a peep hole optimiser and
>> - in the light of modern CPU with powerfull MMUs and triple cache -
>> without any effect anyway.
> 
> Triple cache? L1, L2 and what else? Register renaming? Forwarding?

L1, L2, external  cache - but yes, your are right - external  cache has
become out of fashion again.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: volatile vs aliased

[REH]

"Adrian Knoth" <adi@thur.de> wrote in message 
news:slrndkd6li.38o.adi@ppc201.mipool.uni-jena.de...
> Martin Krischik <krischik@users.sourceforge.net> wrote:
>
>> The truth is that x++ is a cheat and has allways been. x++ only exists
>> because it needs less memory to implement then a peep hole optimiser 
>> and -
>> in the light of modern CPU with powerfull MMUs and triple cache - without
>> any effect anyway.
>
> Triple cache? L1, L2 and what else? Register renaming? Forwarding?
>
L3

Re: volatile vs aliased

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Well, all machine code I have seen so far only have a INC for
> registers. And if you think for it for a sec.: It can't be another
> way, even if there is a INC for memory the CPU still has to read the
> memory increment internally write back.

On the other hand, there is a test-and-set instruction in many
architectures, isn't there? If the memory entity (byte?) is clear, set
it and succeed; if not, fail. This would presumably have to be done
using an uninterruptible read-modify-write cycle.

So it might be _possible_. But whether modern architectures actually
do it is another matter.

We recently had a problem where the BSP for our target board was
upgraded to make VME slave (exported) memory cachable by default. This
required so much in the way of bus snooping etc that if you accessed
the shared memory too often the card would freeze -- not good.

Re: volatile vs aliased

[Dave Thompson]

On Fri, 07 Oct 2005 08:33:06 +0200, Martin Krischik
<krischik@users.sourceforge.net> wrote:

> Rolf wrote:
> 
<snip>
> > Do we have a difference to C/C++ increment operator here? consider
> > 
> > pragma Volatile (x);
> > x := x + 1;   -- (1)
> >         vs.
> > x++;          -- (2)
> > 
> > In the Ada case (1) we are forced to have "read from memory",
> > "increment" and "write to memory" instructions, whereas in C/C++ (2)
> > you can get a single "increment memory" instruction (presuming the
> > mentioned assembler instructions exist on a given processor)
> 
Not officially. In the C standard the abstract semantics for ++x and
x++ with the result unused are the same as x += 1, which in turn is
the same as x = x + 1 except that the _location_ of x is guaranteed
evaluated only once, which makes no difference for a simple variable. 
And in standard C++ the same for the builtin types and hence
operators; on class or enum types, like most operators in C++, these
are user-defined if they exist at all, and thus may do anything.

Of course (memory or other) reads and writes in the abstract machine
can be optimized on a real machine unless volatile, and even for
volatile the C standard (but not C++) contains an escape hatch in '90
6.5.3 or '99 6.7.3p6 that "what constitutes an access to [a volatile
object] is implementation-defined" which means in theory it may be
almost anything as long as it is documented.

> Well, all machine code I have seen so far only have a INC for registers. And
> if you think for it for a sec.: It can't be another way, even if there is a
> INC for memory the CPU still has to read the memory increment internally
> write back.
> 

For some memory busses/interfaces RMW or read-locked-update can be
special operations distinguished by hardware. And in the days of core
this was common, because it could be inserted in the 'middle' of the
destructive-read/rewrite cycle required anyway: PDP-6/10, -11 and VAX
could use memory for any general insn operand except jump target
including destination of 2-op (ADDM rn,mem; ADD #1, mem) or only of
1-op (AddOneSkipnever mem; INC mem). Actually you can and usually do
use this _mode_ for jump target, but that uses the address not the
contents which aren't modified. PDP-5/8/?12 had a specific memory
reference instruction, one of only six (five excluding jump),
Increment (memory) and Skip if Zero.  As I recall on the 8/e this
stretched the normal memory cycle of something like 1.8usec to
something like 2.4usec, significantly less than 2 x 1.8 or whatever.

> The truth is that x++ is a cheat and has allways been. x++ only exists
> because it needs less memory to implement then a peep hole optimiser and -
> in the light of modern CPU with powerfull MMUs and triple cache - without
> any effect anyway.
> 
It's a convenience to write (and read) x in source only once
especially if complicated; of course a preprocessor macro could do the
same and with decent CSE no net effect, but macros are the _most_
unstructured and inelegant part of C so that's hardly better. And C++
to a somewhat lesser extent; C++ works to eliminate _some_ macros.

And _postfix_ like x++ yields the value before the modification, which
prefix and compound x += 1 do not, and is useful for idioms like:
  i = 0;
  while( i < N )
    do_something ( zero_origin_array [i++] );


- David.Thompson1 at worldnet.att.net