RE : [fpc-devel] Sparc v9
For completeness and playing Devil's Advocate, I do have to ask whether pre-v9 (i.e. pre-UltraSPARC) systems are relevant any more. QEMU emulates V8. That's why I had to downgrade. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Chad Berchek schrieb: All the problems we've seen with const used in various contexts with different data types--AnsiString, ShortString, records, etc.--are the result of one fundamental problem, which is the language design. Const is not clearly defined. All problems mentioned stem from this. IMO you should remove the C specs from your brain first, before you start using Pascal. Pascal const parameters are optimization hints in the first place, the write protection of parameters is a less important item instead. Also C++ references are somewhat different from Pascal references, while both can make your code crash when the referenced object is modified or destroyed during subroutine execution - regardless of const or not. Pascal ShortString and AnsiString have no counterpart in the C world. If you don't understand how to use these language features, then use PChar instead, to get back your C feeling with strings. If you are incapable of learning how to write proper code, that allows for const optimization, you better keep your hands off it. If we *knew* that const meant it would be by reference, then that immediately eliminates the confusion in the case of ShortString and records; modifying one instance through several references affects them all, as expected. What the programmer says happens; there can be no bug, except in the programmer's own knowledge. When you know that const parameters typically are passed by reference, what else do you have to know, that's different from C/C++ behaviour? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Sat, Jul 9, 2011 at 4:13 AM, Martin f...@mfriebe.de wrote: On 09/07/2011 00:59, Max Vlasov wrote: On Sat, Jul 9, 2011 at 3:14 AM, Martinf...@mfriebe.de wrote: function CRCConstString(constref Str: string): integer; does what you describ Hmm, it's interesting.. Some observations: - constref is implemented in 2.5.1, right? Unfortunately I can not test it right now in 2.4.2, it refuses to recognize it, but I I want to test it. - In LCL it used only with interfaces and TGuid's, no strings or other structures - there are not much information about constrefs in Lazarus, several posts, the largest part of them is yours, Martin :) so you're probably one of the few who really understand it :) Well the LCL can't use it, if it's trunk only (except if IFDEFed). The LCL should compile with release fpc... See: http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Constref_parameter_modifier - See difference to normal const is that it must be passed by reference. - Note (same as const) it is described as: This modifier means that the compiler can assume that the parameter is constant The assume means that the requirement for constant-ness goes above that what the compiler can enforce (that is: the compiler can enforce only the local var; but constant implies the value by any means of access) With what the compiler does today (afaik) none-constantness would not cause any harm (yet). Unless you count it as harm (and you should) that future FPC may (= is allowed to) compile your code (without any warning or hint) into an exe that behaves different. Thanks for your notes, Martin. I compiled the trunk fpc (2.5.1) and compile the example with constref function TForm33.CRCConstRef(constref Str: string): integer; var i: integer; begin Result:=0; for i:=1 to Length(Str) do Result:=Result + Ord(Str[i]); end; it worked, also the timing is exactly the same as for PString, so your information (PString = constref Str) is indirectly confirmed. Btw, Chad's example also worked I understand that currently it works also because as you mentioned the compiler doesn't apply special optimization, sure it could. But also it's possible to forbid it for this special case. Since ansistring is a special entity, not present in COM at all, so with regard to standards it can be fully internal decision. Also since there are no consref in Delphi as I suppose, they can't be the authority in this regard :) If everything it taken care of, apart from possibly global switch to do const = constref aliasing, lcl also can gradually (when fpc 2.5.1 becomes requirement) replace const with constref in critical places (for example when probable events can be fired). Sure this can break inheritance, so just a thought to think about. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Sparc v9
Ludo Brands wrote: For completeness and playing Devil's Advocate, I do have to ask whether pre-v9 (i.e. pre-UltraSPARC) systems are relevant any more. QEMU emulates V8. That's why I had to downgrade. That seems an entirely adequate reason, since I believe a lot of developers use Qemu. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 9-7-2011 3:29, Martin wrote: On 09/07/2011 02:14, Chad Berchek wrote: Specifically, the way const is now defined (or not...) is disturbing because it leaves out important details. In C++, you can pass by value or reference, or by pointer which is a value but is used to make references. But what's important is you _always_ know what it's going to do. If you pass something by reference and modify that instance via another reference, they're all going to change, because they are the same instance. And if you pass by value, it's the opposite. The point is, though, you always know what it's going to be. Imagine if we took C++ and redefined the pass by reference syntax as the compiler might pass by value or reference, depending what it feels like. Result? Boom. Tons of carefully written code would suddenly break. ... If we *knew* that const meant it would be by reference, then that immediately eliminates the confusion in the case of ShortString and records; modifying one instance through several references affects them all, as expected. What the programmer says happens; there can be no bug, except in the programmer's own knowledge. We do know: http://www.freepascal.org/docs-html/ref/refsu58.html#x135-14500011.4.4 A constant argument is passed by reference if its size is larger than a pointer. It is passed by value if the size is equal or is less then the size of a native pointer. Of course if you want to rely on this, you must ensure the size of your type does ot change (a records definition can be chnaged, and that would have consequences for const param). But then, if you rely on it, but some compiler $IF and $FAIL in the code, to ensure it only compiles if your assumptions are met. Personally I thing this page would be a good place to document the properties of const param with regards to ref-counted types... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Isn't it time to cut this discussion short? const means do not modify! full stop! whatever by reference or value. The rest is bovine extrement. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Sat, Jul 9, 2011 at 12:40 PM, Thaddy tha...@thaddy.com wrote: Isn't it time to cut this discussion short? const means do not modify! full stop! whatever by reference or value. The rest is bovine extrement. Not so fast. As Hans-Peter Diettrich said: Pascal const parameters are optimization hints in the first place, the write protection of parameters is a less important item instead. Is very important, for optimizations, we know if the parameter is passed by reference or value... don't you think? Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Wow, thanks for the insults guys. I didn't realize I was so stupid. You missed my point too, BTW. According to the link given: A constant argument is passed by reference if its size is larger than a pointer. So you always know what the size of a pointer is? If I have this record: TMyRec = record I: Integer; end; Is that passed by value or ref? Is someone compiling on 32-bit or 64? You don't know, and neither does anyone. And that is my point about why having it defined is important. I can't even remember the last time I used C++. My point in mentioning it was only to demonstrate by analogy what could happen if the same ambiguity present in the Pascal construct was present in other well-known languages. All the argument that such bug could exist with shortstrings and records as well is because nobody can say for sure whether they are supposed to be passed by value or by ref--it could be either. With constref, there is no ambiguity. You know it will be by ref, hence there is no question as to whether it's a bug. Otherwise it's just a matter of opinion. I guess my brain is way to tiny to get past the notion that a write once, compile anywhere programming language should be defined in such a way that the meaning of the program doesn't spontaneously change depending on the compilation platform. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 09 Jul 2011, at 03:29, Martin wrote: We do know: http://www.freepascal.org/docs-html/ref/refsu58.html#x135-14500011.4.4 A constant argument is passed by reference if its size is larger than a pointer. It is passed by value if the size is equal or is less then the size of a native pointer. That part of the manual is wrong. What const does is by design completely implementation-dependent (except for cdecl/cppdecl routines, where it behaves the same as in C/C++, and for mwpascal routines, where it behaves the same as in MetroWerks Pascal). And yes, this is different from the meaning of const C and C++ (which is why the meaning is specified separately there). And yes, this means that it can be unsafe if you pass global variables as const and the modify them in the called routine, and that every objection voiced already 10 times in this thread applies. That is how const has always worked since it was introduced in Turbo Pascal. And no, that does not mean this is ideal, but rewriting the entire const handling is not going to happen. Alternatives (such as constref) can be used, and checks can be added, etc, but in general const has always meant in FPC (and Delphi) and will probably always mean I promise that I will not modify this parameter in any way, please help me as far as you can in preventing accidental modifications, and apart from that you can generate any code you want based on that assumption. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 09 Jul 2011, at 18:41, Jonas Maebe wrote: That part of the manual is wrong. What const does is by design completely implementation-dependent (except for cdecl/cppdecl routines, where it behaves the same as in C/C++, and for mwpascal routines, where it behaves the same as in MetroWerks Pascal). And yes, this is different from the meaning of const C and C++ (which is why the meaning is specified separately there). And yes, this means that it can be unsafe if you pass global variables as const and the modify them in the called routine, and that every objection voiced already 10 times in this thread applies. That is how const has always worked since it was introduced in Turbo Pascal. And no, that does not mean this is ideal, but rewriting the entire const handling is not going to happen. And yes, that should all be mentioned in the manual. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Sat, Jul 9, 2011 at 6:55 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Flávio Etrusco schrieb: Isn't this unfortunately encumbered by patents? http://wiki.winehq.org/CompilerExceptionSupport http://yro.slashdot.org/story/05/05/12/1947213/Winelib-Hobbled-by-Exception-Handling-Patent Software patents should not be a problem outside the USA. A nice try, but unimportant for non-resident free software writers and distributors. DoDi I know that, I just wanted to raise the issue, since nobody raised it and I don't/didn't whether all FPC developers lived outside US. I'm brazilian (and live in Brazil) and this is - for now... - not an issue here either. -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
