Re: Pass by reference

[Vinzent 'Gadget' Hoefler <nntp-2004-04@t-domaingrabbing.de>]

Simon Wright wrote:

>Vinzent 'Gadget' Hoefler <nntp-2004-04@t-domaingrabbing.de> writes:
>
>> Simon Wright wrote:
>> 
>> >Vinzent 'Gadget' Hoefler <nntp-2004-04@t-domaingrabbing.de> writes:
>> >
>> >> Pat Rogers wrote:
>> >> 
>> >> >If you made the type volatile that would also force by-reference.
>> >
>> >C.6(18): If a type is atomic or volatile and it is not a by-copy type,
>>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> Yes, but if I understand that part correctly, this is the point. The
>> register-type is just a simple Integer-type:
>
>Sorry, that's what _I_ was trying to say too!

Ok. Got it. :)

[...]
>> >I think you need to use inline assembler to be sure.
>> 
[...]
>> 
>> >And to be really sure you may need to use Volatile => True on the
>> >call, I had to (this was GNAT/PowerPC, by the way).
>> 
>> I'm not sure if I understand... can I actually apply that pragma to
>> a call? Or am I missing something else?
>
>I was talking about your "optimizes the sequence of assignment which I
>need for this register" problem.

Oh.

Well, from what I was trying to understand by looking at the
ASM-output I figured the volatile-"property" of the type just got
lost, *because* it was passed by copy.

>I don't know whether it's available in GCC C inline assembler, but for
>GNAT, System.Machine_Code.Asm looks like
>
>   procedure Asm (
>     Template : String;
>     Outputs  : Asm_Output_Operand_List;
>     Inputs   : Asm_Input_Operand_List;
>     Clobber  : String  := "";
>     Volatile : Boolean := False);
>
>(plus other variants).

Duh. _Now_ I understand. I've never looked at System.Machine_Code.
(IMO inline assembler can considered to be evil in most cases).

>I'm not 100% sure on this, but this code
>
>   with Interfaces;
>   with System.Machine_Code;
>   with System.Storage_Elements;
>
>   procedure Access_Memory_Mapped_Register is
[...]
>   #APP
>           movl #01000000, -65536
>           movl #00000000, -65536
>   #NO_APP

(Despite the fact that this code is not valid, i386 can't load two
constants in one instruction, your intention is clear and would work).

>which looks good .. no 'Access anywhere ..

Yes. Probably I wasn't expressing myself too clear, so I'm trying to
switch to verbose mode. :)

Firstly, if I assign the values to the variable directly the compiled
code is just perfect. No problem here, no inline-assembler needed. Ada
behaves as I expect it to. Fine.

But what I am trying to do is to abstract away some (nasty) behaviour
of the registers (yes, there is more than one, in fact: up to
twenty-four): If I write a new timer value I have to write two byte
values (low-, high-byte) in succession instead of just assigning the
(16-bit) value directly (the 8254 timer only has an 8-bit-data-port).
To make this part a little bit more safe (if you forget to write a
value then - *poof* - everything will screw up) I declared the
"Timer.Write"-procedure that should take one of the
memory-mapped-registers and the value-to-be-written as parameters and
do the nasty stuff with converting the value and extracting high- and
low-byte at this only one place.

Probably a neat idea, but now RM C.6(18) strikes back and passes the
_value_ at the memory address of the register to the procedure
(by-copy) instead of the _address_ of the register (by-reference), I
assign the stuff inside the procedure (means: the compiler is
perfectly allowed to optimize anything away, because it is just
working with a local copy and can't "return" more than 8 bits anyway)
and get the result back that would then be written to the register.

Well, this might be perfectly justified by the mentioned paragraph of
the RM - but is just plain wrong for the real world. Switching to
inline assembler wouldn't help here either, because *at this point* it
is already too late, all I'd get as input would be the value of the
register, not the register (read: pointer to) "itself".

That's why I declared the procedure to take an access parameter
instead of "in out" and now everything is working fine as expected. It
is just the fact that I now use access types in the interface (IMO:
unnecessarily from the point of logic) that bugs me a little bit.

Eventually I should try to switch to use limited types instead to
circumvent this problem?


Vinzent.