volatile vs aliased

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

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

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

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
. @ .

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

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

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

"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

"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

"REH" <spamjunk@stny.rr.com> wrote in message
news:1128606036.713575.3990@z14g2000cwz.googlegrou ps.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.

"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.

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

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

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.

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