Recent

Author Topic: Volatile record field  (Read 875 times)

julkas

  • Full Member
  • ***
  • Posts: 161
  • KISS principle
Volatile record field
« on: July 14, 2019, 01:43:15 pm »
How convert Delphi volatile record field to FPC 3.0.4 ?
Code: Pascal  [Select]
  1. TRec = record
  2.   private
  3.     [Volatile] FValue: Integer;    
  4.     ...
  5.  
http://docwiki.embarcadero.com/RADStudio/Rio/en/Compiler_Attributes
« Last Edit: July 14, 2019, 02:13:47 pm by julkas »
Lazarus 2.0.0 / FPC 3.0.4
----------------------------
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

Thaddy

  • Hero Member
  • *****
  • Posts: 8183
Re: Volatile record field
« Reply #1 on: July 14, 2019, 02:22:00 pm »
In this case [volatile] really means atomic. Depending on platform and/or cpu the integer type is already atomic.

[edit]

A good explanation is here:  https://stackoverflow.com/questions/29958168/are-integer-reads-atomic-in-delphi which also addresses the [volatile].
« Last Edit: July 14, 2019, 02:25:42 pm by Thaddy »
Read the manuals and if you are a professional get a proper education in computer science. Makes the forum a lot cleaner.

julkas

  • Full Member
  • ***
  • Posts: 161
  • KISS principle
Re: Volatile record field
« Reply #2 on: July 14, 2019, 02:38:01 pm »
In this case [volatile] really means atomic. Depending on platform and/or cpu the integer type is already atomic.

[edit]

A good explanation is here:  https://stackoverflow.com/questions/29958168/are-integer-reads-atomic-in-delphi which also addresses the [volatile].
@Thaddy Can you give me FPC 3.0.4 code (not depending on platform and/or cpu)? Thanks.
Lazarus 2.0.0 / FPC 3.0.4
----------------------------
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

Thaddy

  • Hero Member
  • *****
  • Posts: 8183
Re: Volatile record field
« Reply #3 on: July 14, 2019, 02:41:41 pm »
On 32/64 bit Intel/AMD and 32/64 ARM/AARCH it is just:
Code: Pascal  [Select]
  1. TRec = record
  2.   private
  3.      FValue: Integer;

But only because of integer....Or smaller....   

The [volatile] is actually meant for more complex types and that is not yet supported by FPC and works quite bad in Delphi.
The native integer types are related to register size and are atomic on Intel and ARM. On *most* processor families this is probably always true.
« Last Edit: July 14, 2019, 02:49:24 pm by Thaddy »
Read the manuals and if you are a professional get a proper education in computer science. Makes the forum a lot cleaner.

julkas

  • Full Member
  • ***
  • Posts: 161
  • KISS principle
Re: Volatile record field
« Reply #4 on: July 14, 2019, 02:48:10 pm »
works quite bad in Delphi.
Explain please.
Lazarus 2.0.0 / FPC 3.0.4
----------------------------
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

Thaddy

  • Hero Member
  • *****
  • Posts: 8183
Re: Volatile record field
« Reply #5 on: July 14, 2019, 02:50:42 pm »
Define a sub-record larger than can be kept in a single register as a record member as [volatile] and use it in threads......BOOM!
So it is mostly a non-feature in Delphi.  I even wonder if it was only introduced for marketing reasons, since everything that can be represented in a register is always atomic on most modern cpu's.
I even wonder if it has any implementation at all......

Note I quit beta-testing for Delphi some time ago (XE2)  because of something similar. I still have the latest, though, all licensed.
« Last Edit: July 14, 2019, 02:59:58 pm by Thaddy »
Read the manuals and if you are a professional get a proper education in computer science. Makes the forum a lot cleaner.

kupferstecher

  • Sr. Member
  • ****
  • Posts: 267
Re: Volatile record field
« Reply #6 on: July 14, 2019, 03:20:59 pm »
The old volatile discussions with Thaddy...

In my understanding:
Volatile guarantees that the variable accesses in statements are not optimized to registers etc. In fpc there was no such concept (I heard it was introduced lately), so all non local variables have to be dealt as volatile, especially in multithreading applications. A prominent example where "volatility" is needed is the TThreat.Terminated property (boolean). A strong optimization of the loop
 while not terminated do
should recognize that it isn't modified within the loop, so for a non-volatile "terminated" it could be optimized to
 if not terminated do
Of course this would break the code. In case of fpc the volatility is implizit, as said, all non local variables are volatile. But this prevents such optimizations for all variables, also those, that don't need volatile behaviour.

I see a problem in the introduction of a volatile keyword, the backward compatibility. The keyword only makes sense, if optimizations are implemented, that recognize the keyword. If this is the case than old code with the missing keyword gets broken.

@TE: This means in fpc you can just leave the [volatile] away.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 633
Re: Volatile record field
« Reply #7 on: July 14, 2019, 03:30:32 pm »
Integer read/writes on x86/AMD64 are only guaranteed atomic when they are properly aligned (ie. the least-significant 2 bits are 0).

jamie

  • Hero Member
  • *****
  • Posts: 1656
Re: Volatile record field
« Reply #8 on: July 14, 2019, 04:11:35 pm »
Volatile entities is one of those subjects not many understand unless they come from low level
hardware coding..

 But the idea is to inform the compiler that the contents of the variable for example could change
from a background IRQ update or maybe a thread making a change to it.

 So with this little flag in place the compiler can properly address some of its intrinsic functions that
uses a variable in a repetitive way without unexpected changes.
 
 For example the FOR LOOP control statement..
  As the loop is processing  you don't want the counter variable to  make some unexpected change. The
Loop should start with the Volatile value but place it in a worker variable so that the loop can complete
with the initial value successfully, otherwise you'll have some unexpected results.

 Now for the WHILE or REPEAT UNTIL, its a crap shoot I guess and the best thing a person can do is
simple move the value into another value for processing..

 Also, there comes a time if the compiler ever gets smart enough to do this...

Var
 A,B,C,D:Integer := SomeOtherVariable;

WIth this construct, you want to move that value into a temp variable otherwise the SoneOtherVariable
could take a change to something else in the middle of the run...

  The compiler would need to move the initial value into a register to make this work which of course is the
best way..
 
 simply put, if you know the field could change in the middle of a critical moment, then move it to a temp
variable and use that instead.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7232
Re: Volatile record field
« Reply #9 on: July 14, 2019, 04:22:27 pm »
Afaik FPC simply doesn't optimize away loads that way, except when using the LLVM backend, but that is fixed by emitting a volatile for all variables there.

The best way is to put it under a IFDEF HAS_VOLATILE or so, that you set for the very new delphis that have this, and FPC if it ever might have this.

jamie

  • Hero Member
  • *****
  • Posts: 1656
Re: Volatile record field
« Reply #10 on: July 14, 2019, 04:35:44 pm »
Although having the option in the compiler is nice I've always simply moved the critical variable
into a temp variable and processed on that.
 
  A responsible coder can and should understand that plus it makes it more readable because you can
make notes on the fly as to why you are doing it in front of you!  :D

jamie

  • Hero Member
  • *****
  • Posts: 1656
Re: Volatile record field
« Reply #11 on: July 14, 2019, 04:51:00 pm »
No I am not but it looks fine here?

I can't explain it, you are the first to tell me that..

Looking at my past post they look ok to me over here?

jamie

  • Hero Member
  • *****
  • Posts: 1656
Re: Volatile record field
« Reply #12 on: July 14, 2019, 05:02:45 pm »
That isn't the way it looks over here?

I just copied and pasted some post I've made on my clipboard and there are no unexpected line Endings,
it's all displaying the same as I see ..

 It looks like you are using a restrictive screen and you are getting wrap around..

here is a Screen shot I cut out..
« Last Edit: July 14, 2019, 05:07:10 pm by jamie »

jamie

  • Hero Member
  • *****
  • Posts: 1656
Re: Volatile record field
« Reply #13 on: July 14, 2019, 05:08:16 pm »
Please look at the image I pasted in previous message.

jamie

  • Hero Member
  • *****
  • Posts: 1656
Re: Volatile record field
« Reply #14 on: July 14, 2019, 05:12:56 pm »
I don't know what to tell you,. it does not display this way over here.

I am using IE if that makes any difference ?