Thanks so much for the insight Jonas. Heh, Linus is as passionate as I
am sometimes... volatile is evil and all! It makes sense though... and
it will encourage people to write better code.
The 'spinning on a global variable' I admit I've used. In my case it
was in a slave thread that did
On 05/05/2019 19:34, J. Gareth Moreton wrote:
For the volatile intrinsic, was there talk of "volatile" being an
attribute as well? I'm guessing this means declaring something as, for
example "var FTerminated: Boolean volatile;"
See
I'd say the people have spoken. No "safe"! Don't worry, I'm not going
to get angry or anything... I'm appreciating the discussion we're having.
For the volatile intrinsic, was there talk of "volatile" being an
attribute as well? I'm guessing this means declaring something as, for
example
On 05/05/2019 15:31, Marģers . via fpc-devel wrote:
As mentioned in a previous message, fpc trunk
supports a volatile
intrinsic:
http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic
My bad, I didn't know about volatile intrinsic.
So, does it mean that
> As mentioned in a previous message, fpc trunk
supports a volatile
> intrinsic:
>
http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic
My bad, I didn't know about volatile intrinsic.
So, does it mean that compiler is allowed to
optimize any variable, even
On 05/05/2019 14:51, Marģers . via fpc-devel wrote:
As i understand this idea is another way around key word "volatile" in
order to allow compiler perform more optimization.
Then why to go half way introducing "safe", when it's better introduce
"volatile". Not too long ago here was discussion
As i understand this idea is another way around key word "volatile" in order to allow compiler perform more optimization.
Then why to go half way introducing "safe", when it's better introduce "volatile". Not too long ago here was discussion about it, but it was strongly rejected by core team.
I
On 04/05/2019 18:06, J. Gareth Moreton wrote:
I've noticed that my take on coding is somewhat different to others at
times. I tend not to trust the compiler to make the most efficient code.
You generally shouldn't, and it indeed generally won't do it either.
That's why even with the most
J. Gareth Moreton schrieb am So., 5. Mai 2019,
05:11:
> One problem I do have with FPC and its optimiser is that -O4 is
> specifically said that it may cause side-effects and even tongue-in-cheek
> says "beware". To me, this is bad design because it discourages the end
> users from using the
You may be right. Part of Pascal's legacy through Turbo Pascal, Delphi
and Free Pascal is its exceptionally fast compiler. For the more
complex optimisations like data-flow analysis and what I call a "deep
optimiser", there's nothing wrong with it taking a long time (so long as
it is not
On Sat, May 4, 2019 at 5:31 PM J. Gareth Moreton
wrote:
> I figure data-flow analysis will address everything eventually, but I
> can't promise the compiler won't become very inefficient as a result.
>
I mean no offense by this, and note that I think you've done more for FPC
in the last year
Thinking about it more, I can see "safe" as a procedure directive not
working because there are so many contrived cases that can easily break
it, and covering all those cases will make such a feature pretty much
useless.
Talking about attributes, I think a better way is to mark specific
I will say though that I'm reluctant to program any kind of automatic
optimisation that is not thread-safe, even with the 'volatile'
intrinsic. A 'safe' directive is a way of telling the compiler that
"this routine will not be affected by multi-threaded shenanigans" so is
safe to make
Ah, slightly misinterpreted the aliasing thing... yeah, that is a danger
to consider. I'll have to think about that one. That alone may make
safe procedures, at least ones with var and out parameters, relatively
impossible.
Gareth aka. Kit
On 04/05/2019 17:06, J. Gareth Moreton wrote:
This
This is why I posted to the group! You can catch things that I might miss.
For the aliasing issue, I envisioned that var parameters wouldn't be
affected. Since the address is already in a register or on the stack,
it's relatively efficient already.
For the subroutine call, that is indeed a
On 2019-05-03 19:37, J. Gareth Moreton wrote:
By telling the compiler that the procedure (or maybe a whole class) is
thread-safe, you are telling it that you can guarantee that any
objects, fields or global variables that you access are guaranteed to
not suddenly change mid-routine (because
A good question. I did already partially answer it:
"For reasons of safety, the compiler should probably not consider values
thread-safe across the boundary of a try...except or a try...finally
block, not because of the risk of another thread modifying it, but
because an interrupt might,
On Fri, 3 May 2019, J. Gareth Moreton wrote:
This is something I've been thinking about for a while, and I wonder how
practical it is or if it's a good idea - the ability to mark specific
routines as thread-safe with a directive named "safe" or "threadsafe".
By telling the compiler that
This is something I've been thinking about for a while, and I wonder how
practical it is or if it's a good idea - the ability to mark specific
routines as thread-safe with a directive named "safe" or "threadsafe".
By telling the compiler that the procedure (or maybe a whole class) is
19 matches
Mail list logo
