Q: setting an address with pure?

Q: setting an address with pure?

[Simon Wright]

I need to specify the address at which a hardware object appears.

This works:

   PIOA : PIO
     with
       Import,
       Convention => Ada,
       Address => System.Storage_Elements.To_Address (16#400E0E00#);

but means that I can't declare the package Pure (or even Preelaborate).

Is anyone aware of any GNAT feature that would allow such a package to
be Pure? There are similar things in their package Standard, for example
Standard'Address_Size.

I tried

   PIOG : PIO with Import, Convention => Ada;
   for PIOG use at 16#400E1800#;

but, besides warning me that 'use at' is obsolescent, GNAT still expects
System.Address not universal integer.

Re: Q: setting an address with pure?

[G.B.]

On 10.07.15 13:48, Simon Wright wrote:
> I need to specify the address at which a hardware object appears.
>
> This works:
>
>     PIOA : PIO
>       with
>         Import,
>         Convention => Ada,
>         Address => System.Storage_Elements.To_Address (16#400E0E00#);
>
> but means that I can't declare the package Pure (or even Preelaborate).
>
> Is anyone aware of any GNAT feature that would allow such a package to
> be Pure?

I know this isn't an answer, but still, do you need
PIOA'Address fixed at compile time? Elsewhere? Could
some tool that works after compilation take care of
placement?

Re: Q: setting an address with pure?

[Simon Wright]

"G.B." <bauhaus@futureapps.invalid> writes:

> On 10.07.15 13:48, Simon Wright wrote:
>> I need to specify the address at which a hardware object appears.
>>
>> This works:
>>
>>     PIOA : PIO
>>       with
>>         Import,
>>         Convention => Ada,
>>         Address => System.Storage_Elements.To_Address (16#400E0E00#);
>>
>> but means that I can't declare the package Pure (or even Preelaborate).
>>
>> Is anyone aware of any GNAT feature that would allow such a package to
>> be Pure?
>
> I know this isn't an answer, but still, do you need PIOA'Address fixed
> at compile time? Elsewhere? Could some tool that works after
> compilation take care of placement?

The way that Maciej did this was to fix PIOB in the linker
script. Personally I prefer to do it in Ada, that's all.

Re: setting an address with pure?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyy4iokzci.fsf@pushface.org...
>I need to specify the address at which a hardware object appears.
>
> This works:
>
>   PIOA : PIO
>     with
>       Import,
>       Convention => Ada,
>       Address => System.Storage_Elements.To_Address (16#400E0E00#);
>
> but means that I can't declare the package Pure (or even Preelaborate).

You can't have a variable at library level in a Pure package (there shall be 
no state), so it makes no sense at all for such a package to contain any 
hardware objects.

I don't see any reason why this can't be Preelaborated 
(System.Storage_Elements is Pure, after all); that depends on the 
initialization of the type PIO (it needs to have 
"preelaborable_initialization"; use the pragma if in doubt).

                            Randy.

Re: setting an address with pure?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lyy4iokzci.fsf@pushface.org...
>>I need to specify the address at which a hardware object appears.
>>
>> This works:
>>
>>   PIOA : PIO
>>     with
>>       Import,
>>       Convention => Ada,
>>       Address => System.Storage_Elements.To_Address (16#400E0E00#);
>>
>> but means that I can't declare the package Pure (or even Preelaborate).
>
> You can't have a variable at library level in a Pure package (there
> shall be no state), so it makes no sense at all for such a package to
> contain any hardware objects.
>
> I don't see any reason why this can't be Preelaborated
> (System.Storage_Elements is Pure, after all); that depends on the
> initialization of the type PIO (it needs to have
> "preelaborable_initialization"; use the pragma if in doubt).

GNAT says that the call to System.Storage_Elements.To_Address is invalid
because "non-static call not allowed in preelaborated unit", whether
Preelaborable_Initialization is applied or not. I take it that
To_Address isn't static because its result type isn't scalar? (4.9(19))

I think this may be a failure in a GNAT extension; To_Address has pragma
Pure_Function applied to it, and[2]

   "It specifies that the function Entity is to be considered pure for
   the purposes of code generation. This means that the compiler can
   assume that there are no side effects, and in particular that two
   calls with identical arguments produce the same result. It also means
   that the function can be used in an address clause."

[1] http://www.ada-auth.org/standards/12rm/html/RM-4-9.html#p19
[2] https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Pure_005fFunction.html

Re: Q: setting an address with pure?

[Brian Drummond]

On Fri, 10 Jul 2015 12:48:29 +0100, Simon Wright wrote:

> I need to specify the address at which a hardware object appears.
> 
> This works:
> 
>    PIOA : PIO
>      with
>        Import,
>        Convention => Ada,
>        Address => System.Storage_Elements.To_Address (16#400E0E00#);
> 
> but means that I can't declare the package Pure (or even Preelaborate).
> 
> Is anyone aware of any GNAT feature that would allow such a package to
> be Pure? There are similar things in their package Standard, for example
> Standard'Address_Size.
> 
> I tried
> 
>    PIOG : PIO with Import, Convention => Ada;
>    for PIOG use at 16#400E1800#;
> 
> but, besides warning me that 'use at' is obsolescent, GNAT still expects
> System.Address not universal integer.

Does the following work for you? It seems to work in the MSP430 Ada 
compiler (based on gcc4.7.2) ... has anything changed in gcc5.1 to make 
this illegal?

-- Brian

with Interfaces;               use Interfaces;    
--   make unsigned_n visible 

package MSP.adc10 is
 
   pragma Preelaborate;
 
 
   adc10dtc0              : unsigned_8;     --  ADC10 Data Transfer 
Control 0 
   Pragma Volatile(adc10dtc0);
   For adc10dtc0'Address use   16#48#;
...
end MSP.adc10;

Re: Q: setting an address with pure?

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Does the following work for you? It seems to work in the MSP430 Ada 
> compiler (based on gcc4.7.2) ... has anything changed in gcc5.1 to make 
> this illegal?
>
> -- Brian
>
> with Interfaces;               use Interfaces;    
> --   make unsigned_n visible 
>
> package MSP.adc10 is
>  
>    pragma Preelaborate;
>  
>  
>    adc10dtc0              : unsigned_8;     --  ADC10 Data Transfer 
> Control 0 
>    Pragma Volatile(adc10dtc0);
>    For adc10dtc0'Address use   16#48#;
> ...
> end MSP.adc10;

   128.    PIOG : PIO with Volatile, Convention => Ada;
   129.    for PIOG'Address use 16#400E1C00#;
                                |
        >>> expected private type "System.Address"
        >>> found type universal integer

(same with GNAT GPL 2015)

Re: Q: setting an address with pure?

[AdaMagica]

>    128.    PIOG : PIO with Volatile, Convention => Ada;
>    129.    for PIOG'Address use 16#400E1C00#;
>                                 |
>         >>> expected private type "System.Address"
>         >>> found type universal integer

IIRC, the syntax is
for X'Address use at Somewhere;

Re: Q: setting an address with pure?

[Simon Wright]

AdaMagica <christ-usch.grein@t-online.de> writes:

>>    128.    PIOG : PIO with Volatile, Convention => Ada;
>>    129.    for PIOG'Address use 16#400E1C00#;
>>                                 |
>>         >>> expected private type "System.Address"
>>         >>> found type universal integer
>
> IIRC, the syntax is
> for X'Address use at Somewhere;

for X use at Somewhere;

but

   128.    PIOG : PIO with Volatile, Convention => Ada;
   129.    for PIOG use at 16#400E1C00#;
           1               3
        >>> warning: at clause is an obsolescent feature (RM J.7(2))
        >>> warning: use address attribute definition clause instead
        >>> expected private type "System.Address"
        >>> found type universal integer

LRM83 13.5 [1]:

   "The expression given after the reserved word at must be of the type
   ADDRESS defined in the package SYSTEM"

BUT in the example lower down

    for CONTROL use at 16#0020#; -- assuming that SYSTEM.ADDRESS is an integer 
    type

which assumption doesn't hold.

[1] http://archive.adaic.com/standards/83lrm/html/lrm-13-05.html

Re: Q: setting an address with pure?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyd1zylqfo.fsf@pushface.org...
>
>>>    128.    PIOG : PIO with Volatile, Convention => Ada;
>>>    129.    for PIOG'Address use 16#400E1C00#;
>>>                                 |
>>>         >>> expected private type "System.Address"
>>>         >>> found type universal integer

Of course. It should be:

for PIOG'Address use System.Storage_Elements.To_Address(16#400E1C00#);

Since System.Storage_Elements is Pure, that should work fine here. You 
seemed to indicate that it did not. What's the error message for that?

                             Randy.

Re: setting an address with pure?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lypp3zkueh.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:lyy4iokzci.fsf@pushface.org...
>>>I need to specify the address at which a hardware object appears.
>>>
>>> This works:
>>>
>>>   PIOA : PIO
>>>     with
>>>       Import,
>>>       Convention => Ada,
>>>       Address => System.Storage_Elements.To_Address (16#400E0E00#);
>>>
>>> but means that I can't declare the package Pure (or even Preelaborate).
>>
>> You can't have a variable at library level in a Pure package (there
>> shall be no state), so it makes no sense at all for such a package to
>> contain any hardware objects.
>>
>> I don't see any reason why this can't be Preelaborated
>> (System.Storage_Elements is Pure, after all); that depends on the
>> initialization of the type PIO (it needs to have
>> "preelaborable_initialization"; use the pragma if in doubt).
>
> GNAT says that the call to System.Storage_Elements.To_Address is invalid
> because "non-static call not allowed in preelaborated unit", whether
> Preelaborable_Initialization is applied or not. I take it that
> To_Address isn't static because its result type isn't scalar? (4.9(19))

To_Address is a function, not an operator. 4.9(19) does not apply (it only 
applies to predefined operators, and To_Address is neither an operator nor 
predefined [language-defined /= predefined]). There is no way to have a 
static function in Ada to date. (We've been taking about adding an aspect on 
expression functions to allow that.)

This seems like a bug in Ada to me, it's a consequence of making Address a 
private type (it's not private in Janus/Ada because we didn't want the 
incompatibility that would have resulted, so I've never seen this before). 
It certainly seems wrong that an address clause for a hardware entity can't 
be used in a preelaborated unit.

> I think this may be a failure in a GNAT extension; To_Address has pragma
> Pure_Function applied to it, and[2]
>
>   "It specifies that the function Entity is to be considered pure for
>   the purposes of code generation. This means that the compiler can
>   assume that there are no side effects, and in particular that two
>   calls with identical arguments produce the same result. It also means
>   that the function can be used in an address clause."
>
> [1] http://www.ada-auth.org/standards/12rm/html/RM-4-9.html#p19
> [2] https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Pure_005fFunction.html

Possibly. In "pedantic" mode, the function would have to be an error because 
implementation-defined stuff shouldn't be changing basic properties (like 
staticness) of language-defined subprograms. But it certainly makes sense to 
work-around this language design flaw.

I'd encourage you to post this problem on Ada-Comment, so that it gets on 
the ARG agenda. (If we end up with a static function aspect, it would make 
sense to apply it to To_Address.)

                                    Randy.

Re: Q: setting an address with pure?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lyd1zylqfo.fsf@pushface.org...
>>
>>>>    128.    PIOG : PIO with Volatile, Convention => Ada;
>>>>    129.    for PIOG'Address use 16#400E1C00#;
>>>>                                 |
>>>>         >>> expected private type "System.Address"
>>>>         >>> found type universal integer
>
> Of course. It should be:
>
> for PIOG'Address use System.Storage_Elements.To_Address(16#400E1C00#);
>
> Since System.Storage_Elements is Pure, that should work fine here. You
> seemed to indicate that it did not. What's the error message for that?

non-static call not allowed in preelaborated unit

Re: setting an address with pure?

[RasikaSrinivasan]

Does it have to be pure?

I use Pragma Restrictions( No_Elaboration_Code );

then :

   DACMAP : DAC_CR_Type
          with Volatile ,
          Address => System'To_Address( 16#NNNN_NNNN# ) ;

I am not sure if this is what you are aiming for but appears to work so for. NNNN_NNNN above is the base address of the DAC map as provided by the STM32 Ref Manual.

cheers, srini

Re: setting an address with pure?

[Simon Wright]

"RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:

> Does it have to be pure?
>
> I use Pragma Restrictions( No_Elaboration_Code );

I don't have any objection to elaboration code per se, I just wanted to
get as near to Pure as I could.

I did use that restriction for a Cortex Reset_Handler, which is called
by the hardware before any elaboration occurs at all.

> then :
>
>    DACMAP : DAC_CR_Type
>           with Volatile ,
>           Address => System'To_Address( 16#NNNN_NNNN# ) ;
>
> I am not sure if this is what you are aiming for but appears to work
> so for. NNNN_NNNN above is the base address of the DAC map as provided
> by the STM32 Ref Manual.

This was just what I wanted, thanks very much!

This is actually in the secret documentation: I would refer to the
gcc.gnu.org version, but it's unreachable at this moment.

http://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/implementation_defined_attributes.html#attribute-to-address

Re: setting an address with pure?

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> "RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:
>
>> Does it have to be pure?
>>
>> I use Pragma Restrictions( No_Elaboration_Code );
>
> I don't have any objection to elaboration code per se, I just wanted to
> get as near to Pure as I could.
>
> I did use that restriction for a Cortex Reset_Handler, which is called
> by the hardware before any elaboration occurs at all.
>
>> then :
>>
>>    DACMAP : DAC_CR_Type
>>           with Volatile ,
>>           Address => System'To_Address( 16#NNNN_NNNN# ) ;
>>
>> I am not sure if this is what you are aiming for but appears to work
>> so for. NNNN_NNNN above is the base address of the DAC map as provided
>> by the STM32 Ref Manual.
>
> This was just what I wanted, thanks very much!
>
> This is actually in the secret documentation: I would refer to the
> gcc.gnu.org version, but it's unreachable at this moment.
>
> http://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/implementation_defined_attributes.html#attribute-to-address

See also pragma Allow_Integer_Address!!!

Re: setting an address with pure?

[Mark Lorenzen]

On Monday, July 13, 2015 at 9:10:10 PM UTC+2, Randy Brukardt wrote:

> It certainly seems wrong that an address clause for a hardware entity can't 
> be used in a preelaborated unit.

I have been bitten by this restriction several times and it's a real pain.

> I'd encourage you to post this problem on Ada-Comment, so that it gets on 
> the ARG agenda. (If we end up with a static function aspect, it would make 
> sense to apply it to To_Address.)

Yes please - the current restriction prevents many low-level I/O packages from having preelaborable elaboration, which transitively prevents a whole I/O library from having preelaborable elaboration.

Regards,

MarkL

Re: Q: setting an address with pure?

[Brian Drummond]

On Sat, 11 Jul 2015 14:30:14 +0100, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> Does the following work for you?
>>    For adc10dtc0'Address use   16#48#;

> 
>    128.    PIOG : PIO with Volatile, Convention => Ada;
>    129.    for PIOG'Address use 16#400E1C00#;
>                                 |
>         >>> expected private type "System.Address"
>         >>> found type universal integer
> 
> (same with GNAT GPL 2015)

Thank you - and Rasika Srinivasan - forthis conversation. When I get back 
to the MSP430 version I'll retrofit this.

-- Brian

Re: Q: setting an address with pure?

[rrr.eee.27]

On Tuesday, July 14, 2015 at 2:25:34 PM UTC+2, Brian Drummond wrote:
> On Sat, 11 Jul 2015 14:30:14 +0100, Simon Wright wrote:
> 
> > Brian Drummond writes:
> > 
> >> Does the following work for you?
> >>    For adc10dtc0'Address use   16#48#;
> 
> > 
> >    128.    PIOG : PIO with Volatile, Convention => Ada;
> >    129.    for PIOG'Address use 16#400E1C00#;
> >                                 |
> >         >>> expected private type "System.Address"
> >         >>> found type universal integer
> > 
> > (same with GNAT GPL 2015)
> 
> Thank you - and Rasika Srinivasan - forthis conversation. When I get back 
> to the MSP430 version I'll retrofit this.
> 
> -- Brian

Brian, as far as I remember you started MSP430-Ada as a copy of AVR-Ada. I made the type System.Address globaly visible as a 32-bit unsigned. That's why the above statements work in AVR-Ada and probably in MSP-Ada

Rolf

Re: Q: setting an address with pure?

[Simon Wright]

rrr.eee.27@gmail.com writes:

> On Tuesday, July 14, 2015 at 2:25:34 PM UTC+2, Brian Drummond wrote:
>> On Sat, 11 Jul 2015 14:30:14 +0100, Simon Wright wrote:
>> 
>> > Brian Drummond writes:
>> > 
>> >> Does the following work for you?
>> >>    For adc10dtc0'Address use   16#48#;
>> 
>> > 
>> >    128.    PIOG : PIO with Volatile, Convention => Ada;
>> >    129.    for PIOG'Address use 16#400E1C00#;
>> >                                 |
>> >         >>> expected private type "System.Address"
>> >         >>> found type universal integer
>> > 
>> > (same with GNAT GPL 2015)
>> 
>> Thank you - and Rasika Srinivasan - forthis conversation. When I get
>> back to the MSP430 version I'll retrofit this.
>
> Brian, as far as I remember you started MSP430-Ada as a copy of
> AVR-Ada. I made the type System.Address globaly visible as a 32-bit
> unsigned. That's why the above statements work in AVR-Ada and probably
> in MSP-Ada

Whereas I was minimising the differences from a standard GNAT RTS. I
never even thought of making this sort of change!

Re: Q: setting an address with pure?

[Brian Drummond]

On Wed, 15 Jul 2015 08:50:06 -0700, rrr.eee.27 wrote:

> On Tuesday, July 14, 2015 at 2:25:34 PM UTC+2, Brian Drummond wrote:
>> On Sat, 11 Jul 2015 14:30:14 +0100, Simon Wright wrote:
>> 
>> > Brian Drummond writes:
>> > 
>> >> Does the following work for you?
>> >>    For adc10dtc0'Address use   16#48#;
>> 
>> 
>> >    128.    PIOG : PIO with Volatile, Convention => Ada;
>> >    129.    for PIOG'Address use 16#400E1C00#;
>> >                                 |
>> >         >>> expected private type "System.Address"
>> >         >>> found type universal integer
>> > 
>> > (same with GNAT GPL 2015)
>> 
>> Thank you - and Rasika Srinivasan - forthis conversation. When I get
>> back to the MSP430 version I'll retrofit this.
>> 
>> -- Brian
> 
> Brian, as far as I remember you started MSP430-Ada as a copy of AVR-Ada.

Indeed, yes! AVR-Ada was both the inspiration, and specifically, your RTS 
was the best candidate for a starting point for the MSP430 RTS. 

Though I treat it as a component, to potentially allow the substitution 
of another RTS. (I'm not sure if that's possible in AVR-Ada).

> I made the type System.Address globaly visible as a 32-bit unsigned.
> That's why the above statements work in AVR-Ada and probably in MSP-Ada
> 
> Rolf

Ah! Well if that is permitted by the LRM (and obviously, only for targets 
where it is valid) it certainly makes life easier! 

I think it's a reasonable decision, since these packages are explicitly 
not portable to any other target (where System.Address could be something 
else) anyway.

That little gem makes me glad I posted!

-- Brian

Re: Q: setting an address with pure?

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

>> That's why the above statements work in AVR-Ada and probably in MSP-Ada
>> 
>> Rolf
>
> Ah! Well if that is permitted by the LRM (and obviously, only for
> targets where it is valid) it certainly makes life easier!
>
> I think it's a reasonable decision, since these packages are
> explicitly not portable to any other target (where System.Address
> could be something else) anyway.

See also pragma Allow_Integer_Address[1] - not sure whether it's reached
publicly accessible compilers yet.

[1] http://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/implementation_defined_pragmas.html#pragma-allow-integer-address

Re: Q: setting an address with pure?

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:mo7t28$6h2$1@dont-email.me...
> On Wed, 15 Jul 2015 08:50:06 -0700, rrr.eee.27 wrote:
...
>> I made the type System.Address globaly visible as a 32-bit unsigned.
>> That's why the above statements work in AVR-Ada and probably in MSP-Ada
>
> Ah! Well if that is permitted by the LRM (and obviously, only for targets
> where it is valid) it certainly makes life easier!

It's permitted by the RM. There is Implementation Advice that System.Address 
be a private type, but of course the reason that it is advice is that it 
might not be appropriate to all implementations. In this particular case, 
though, its advice mainly because it would have been incompatible on some 
implementations to make it private (Janus/Ada is in that category); I think 
the feeling was that new implementations should have it private. (But we now 
know that's clearly wrong if preelaboration is going to be used with 
hardware access.)

Hopefully, Ada 202x will find a solution to this problem (and maybe even in 
the 2018 update), so it's fixed for good rather than depending on the 
goodness of your RTS implementer (many who are likely to be unaware of this 
problem).

                               Randy.