Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread wkitty42
On 12/19/2015 11:33 AM, Sven Barth wrote: Am 19.12.2015 15:54 schrieb [...] not really... backwards compatibility and all that... borland's TP and BP do the same... at least back as far as v6... i can't get to my v5 or v3 to test but i daresay that they, too, do the same... looking forward fro

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread Sven Barth
Am 19.12.2015 15:54 schrieb : > > On 12/18/2015 06:16 AM, R. Diez wrote: > [...] > >> > "for loop variable value reliable after loop?" >> > http://lists.freepascal.org/pipermail/fpc-pascal/2015-October/045446.html >> > [...] >> > language behaviour that may be unexpected if you are used to >>

Re: [fpc-pascal] Lack of 'volatile' a serious issue.

2015-12-19 Thread Jonas Maebe
On 19/12/15 15:58, Tobias Giesen wrote: I optimize my code in such a way that compiler optimizations are not really needed, but obviously I wouldn't say no if they were reliable. Could it be related to this discussion? Do optimizations make apps less thread safe in FPC? No. The fact that your

Re: [fpc-pascal] Lack of 'volatile' a serious issue.

2015-12-19 Thread Tobias Giesen
Hello, I am interested in this problem too. My app is highly multithreaded, working mostly with TObject descendants such as TStringList and TCollections. I am ensuring thread safety thru CriticalSections. In fact I have made my own TThreadSafeStringList. I have been distributing the app with opti

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread wkitty42
On 12/18/2015 06:16 AM, R. Diez wrote: [...] > "for loop variable value reliable after loop?" > http://lists.freepascal.org/pipermail/fpc-pascal/2015-October/045446.html > [...] > language behaviour that may be unexpected if you are used to > e.g. C, but that is considered normal in Pascal

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread Sven Barth
Am 19.12.2015 14:19 schrieb "Jonas Maebe" : > > On 18/12/15 10:12, Lukasz Sokol wrote: >> >> I know FreePascal is not Linux, the Team is not Torvalds etc;) >> but have you seen this ? >> >> https://lwn.net/Articles/233482/ > > > Maybe a "volatile" intrinsic, just like we already have an "unaligned"

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread Jonas Maebe
On 18/12/15 10:12, Lukasz Sokol wrote: I know FreePascal is not Linux, the Team is not Torvalds etc;) but have you seen this ? https://lwn.net/Articles/233482/ Maybe a "volatile" intrinsic, just like we already have an "unaligned" intrinsic, would indeed be a better idea than adding the possi

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread Florian Klaempfl
Am 18.12.2015 um 12:16 schrieb R. Diez: > > I see. Based on that information, and on the issue of function calls > crossing units, I guess you could rephrase that in much less-friendly > way. I'm playing evil advocate now: "FreePascal is so simple it can only > optimise properly the kind of hand-w

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

2015-12-19 Thread Mark Morgan Lloyd
R. Diez wrote: Issuing a generic memory barrier is workable, but it kills performance, as all variables will be reloaded again. Performance does matter when working on microcontrollers. Could I ask for a reality check here. That sounds more like a cache flush, while a membar only ensures tha