Recent

Author Topic: Statement as memory barrier for globals ("volatile")  (Read 28602 times)

jamie

  • Hero Member
  • *****
  • Posts: 6077
Re: Statement as memory barrier for globals ("volatile")
« Reply #15 on: November 21, 2017, 11:33:55 pm »
I think you miss understand it.

Volatile simple means that if for example in a loop you were to keep referring to a variable
for a value, the compiler should not move that value into a register and never reference that
variable from memory again while in that loop.

 Moving values from memory to registers is a standard practice but the point is, the next
time around the code is to examine that memory variable, it is to reload that register again
from the same location!....

 I really can't think of a case where fpc would do that anyway other than an internal value set
at the start of a loop, like a for Loop statement. That counter can start from a memory variable or
constant and be moved into a register for the remainder of the loop, but listen, it is part of the loop control
not the monitoring of live data changes from sources out side your current block.

The only true wisdom is knowing you know nothing

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Statement as memory barrier for globals ("volatile")
« Reply #16 on: November 22, 2017, 06:16:04 am »
Moving values from memory to registers is a standard practice but the point is, the next
time around the code is to examine that memory variable, it is to reload that register again
from the same location!
....

FPC does not do that when using writable typed const, and that was the point I tried to show in my previous post. Hence the conclusion that writable typed const are not equivalent to volatile variables in C.

Here is a similar C example:
Code: C  [Select][+][-]
  1. int main(void)
  2. {
  3.     volatile int t = 0;
  4.     t = 1;
  5.     int i;
  6.     i = t;
  7.     i = t;
  8.     i = t;
  9.     i = t;
  10.     i = t;
  11.     i = t;
  12.     i = t;
  13.     i = t;
  14.     i = t;
  15.     i = t;
  16. }

Here is the relevant part of the emitted assembly:
Code: ASM  [Select][+][-]
  1. LVL0:
  2.         .loc 1 5 0
  3.         movl    $0, 12(%esp)
  4.         .loc 1 6 0
  5.         movl    $1, 12(%esp)
  6.         .loc 1 8 0
  7.         movl    12(%esp), %eax
  8.         .loc 1 9 0
  9.         movl    12(%esp), %eax
  10.         .loc 1 10 0
  11.         movl    12(%esp), %eax
  12.         .loc 1 11 0
  13.         movl    12(%esp), %eax
  14.         .loc 1 12 0
  15.         movl    12(%esp), %eax
  16.         .loc 1 13 0
  17.         movl    12(%esp), %eax
  18.         .loc 1 14 0
  19.         movl    12(%esp), %eax
  20.         .loc 1 15 0
  21.         movl    12(%esp), %eax
  22.         .loc 1 16 0
  23.         movl    12(%esp), %eax
  24.         .loc 1 17 0
  25.         movl    12(%esp), %eax
  26.         .loc 1 18 0

Notice how it reads the value from memory every time: movl   12(%esp), %eax

I really can't think of a case where fpc would do that anyway other than an internal value set
at the start of a loop, like a for Loop statement. That counter can start from a memory variable or
constant and be moved into a register for the remainder of the loop, but listen, it is part of the loop control
not the monitoring of live data changes from sources out side your current block.

I really think you should try to see the assembly code emitted for the following for loops:
Code: C  [Select][+][-]
  1.   for(i=0;i<10;i++)
  2.     t = i;
  3.  
  4.   for(t=0;t<10;t++)
  5.     i = t;
« Last Edit: November 22, 2017, 06:29:46 am by engkin »

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Statement as memory barrier for globals ("volatile")
« Reply #17 on: November 22, 2017, 11:45:25 am »
So we have to find one example where this claim does not seem to be true:
It's a good method, but could also mean the compiler is buggy :)
I tried the same with globals and with globals with absolute modifier and some statemets are optimised away (Tested on i368).

Quote
I don't think anyone has a reference because it does not exist.
Seems like. At least for FPC in general. Perhaps the implementations for target embedded are different. As the registers are defined as globals with absolute address, this must work, otherwise it would be nonsence.

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Statement as memory barrier for globals ("volatile")
« Reply #18 on: November 22, 2017, 07:57:53 pm »
So we have to find one example where this claim does not seem to be true:
It's a good method, but could also mean the compiler is buggy :)
It is hard to say, as it does not produce unexpected results, or violates the documentation. Maybe just lacks a feature.

I tried the same with globals and with globals with absolute modifier and some statemets are optimised away (Tested on i368).
As you can see, it is not there. FPC does not have any thing similar to volatile variables in C.

Quote
I don't think anyone has a reference because it does not exist.
Seems like. At least for FPC in general. Perhaps the implementations for target embedded are different. As the registers are defined as globals with absolute address, this must work, otherwise it would be nonsence.
I doubt it. But even if a global variable with absolute modifier works, that by itself solves part of the problem, the other part when you need a variable for the general case, not one specific register.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Statement as memory barrier for globals ("volatile")
« Reply #19 on: November 22, 2017, 08:57:09 pm »
So where to address that issue?
In the bug tracker as feature request?

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Statement as memory barrier for globals ("volatile")
« Reply #20 on: November 22, 2017, 09:26:02 pm »
YES, with a patch implementing it.  :D

You tried here, and most likely no more responses will be added to this thread. So still two more places: the bug tracker and the mailing list. Most core developers seem to prefer the mailing list over the forums.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Statement as memory barrier for globals ("volatile")
« Reply #21 on: November 23, 2017, 11:35:08 am »
So I'll suppose the 'globals solution' in the bug tracker.

with a patch implementing it.  :D
I would if I could~


Regards

Thaddy

  • Hero Member
  • *****
  • Posts: 14169
  • Probably until I exterminate Putin.
Re: Statement as memory barrier for globals ("volatile")
« Reply #22 on: November 23, 2017, 11:43:29 am »
FPC does not do that when using writable typed const, and that was the point I tried to show in my previous post. Hence the conclusion that writable typed const are not equivalent to volatile variables in C.
It should be. Otherwise it is a bug and not a feature request.
But you showed indeed a problem. Very eloquently.
« Last Edit: November 23, 2017, 11:45:37 am by Thaddy »
Specialize a type, not a var.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Statement as memory barrier for globals ("volatile")
« Reply #23 on: November 23, 2017, 12:17:51 pm »
I filed a feature request in the bug tracker:
https://bugs.freepascal.org/view.php?id=32721

Thaddy, in the fpc language reference I didn't find anything that supports your claim. This means even if the way you say is the correct pascal way, than for fpc this would mean to be a new feature, right?

Thaddy

  • Hero Member
  • *****
  • Posts: 14169
  • Probably until I exterminate Putin.
Re: Statement as memory barrier for globals ("volatile")
« Reply #24 on: November 23, 2017, 12:41:55 pm »
"In computer programming, particularly in the C, C++, C#, and Java programming languages, the volatile keyword indicates that a value may change between different accesses, even if it does not appear to be modified. This keyword prevents an optimizing compiler from optimizing away subsequent reads or writes and thus incorrectly reusing a stale value or omitting writes."

Which is EXACTLY the same as an assignable typed const behaves.

I rest my plea... Back to school as far as I am concerned.
« Last Edit: November 23, 2017, 12:43:40 pm by Thaddy »
Specialize a type, not a var.

ccrause

  • Hero Member
  • *****
  • Posts: 843
Re: Statement as memory barrier for globals ("volatile")
« Reply #25 on: November 23, 2017, 12:52:30 pm »
Volatile has been debated in the past, see e.g. this thread. This reply by Jonas to another thread suggests that (at least in 2015) in FPC there isn't a full equivalent of "volatile".  From Jonas's reply it appears that the use of the "absolute" keyword implies the compiler "will never optimize their accesses".  Also Jonas stated the following: "In FPC, every statement is basically considered to be a compiler-level memory barrier for accesses to global variables."

Thaddy

  • Hero Member
  • *****
  • Posts: 14169
  • Probably until I exterminate Putin.
Re: Statement as memory barrier for globals ("volatile")
« Reply #26 on: November 23, 2017, 12:55:49 pm »
I am quite sure Jonas will to some extend support my explanation.
The difficulty on this forum is always that we have users (often extremely good programmers!) and users that are third grade computer scientists (like me) >:D 8-) O:-)

Funny thing is you did not read that answer carefully:
"The reason the need for volatile on embedded systems is far less in FPC,
is the existence of the "absolute" keyword. In C, you have to declare
all of those memory mapped registers as volatile pointers, because
otherwise things will get optimised wrongly. In FPC, you can declare
them as variables that are "absolute" at some address, and the compiler
will never optimise their accesses. Only if you would take the address
of one of these variables and store it in a pointer, you would need
"volatile" in this context.
"

Dunno what you think, but..... <grin>

Probably overlooked assignable typed constants and mentioned absolute. All covered. < very, very, grumpy  >:D >:D >:D >:D >:D>
« Last Edit: November 23, 2017, 01:05:51 pm by Thaddy »
Specialize a type, not a var.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Statement as memory barrier for globals ("volatile")
« Reply #27 on: November 23, 2017, 01:13:32 pm »
"indicates that a value may change between different accesses, even if it does not appear to be modified."
Means the following code line
  writeln(Inttostr(aVolatile)); writeln(Inttostr(aVolatile));
may print two different values.

The volatile concept is clear. But where do you connect it to the writable typed constant? From the language reference:
Quote
2.2 Typed constants
[...]
Contrary to ordinary constants, a value can be assigned to them at run-time. This is an old concept from Turbo Pascal, which has been replaced with support for initialized variables: For a detailed description, see section 4.4, page 223.
[...]
Again where do you see the connection? It doesn't say anything about optimisation, it just says that the constant will behave like a variable.

@ccrause:
The sentence "In FPC, every statement is basically considered to be a compiler-level memory barrier for accesses to global variables." isn't true for current compilers (optimisation is done by the compiler). For target embedded it may be true, but its not documented.

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Statement as memory barrier for globals ("volatile")
« Reply #28 on: November 23, 2017, 03:32:19 pm »
FPC does not do that when using writable typed const, and that was the point I tried to show in my previous post. Hence the conclusion that writable typed const are not equivalent to volatile variables in C.
It should be. Otherwise it is a bug and not a feature request.
But you showed indeed a problem. Very eloquently.
Your insistence is impressive.
  • When was it functioning? I just tried an older development version of FPC (2.7.1 from 2013). The results are funnier.
  • It is not documented, can you explain why? Do you think a bug report is needed against the documentation?
  • How about Delphi, is it the same? Can you test the code in this post using Delphi (any version)?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Statement as memory barrier for globals ("volatile")
« Reply #29 on: November 23, 2017, 07:20:14 pm »
Which is EXACTLY the same as an assignable typed const behaves.

NO!

It is not.

typed (writable) constants are prevented from being inlined. That is all.

Otherwise they can still be optimized

Code: Pascal  [Select][+][-]
  1. const a: integer = 1;
  2. ...
  3. begin
  4.   b := a;
  5.   c := a;
  6. end;
  7.  

The compiler can optimize this to
- load a into a register
- write the register to b
- write the register to c

meaning b and c will always be the same.

In case of volatile b and c may differ, if a was changed by something outside the programs flow.

Therefore "volatile" prevents caching of a in a register between the 2 statements



 

TinyPortal © 2005-2018