Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Daniƫl Mantione
Op Thu, 7 Jul 2011, schreef Chad Berchek: The problem comes down to the specs though, or rather the lack thereof. As I have searched the web and read some docs at Embarcadero, things have only become more ambiguous. You are looking in the wrong places. Both Turbo Pascal and Delphi came

Re: [fpc-devel] Const optimization is a serious bug (What nexy)

2011-07-08 Thread Martin
On 08/07/2011 11:05, Jonas Maebe wrote: On 08 Jul 2011, at 05:51, Chad Berchek wrote: I'm more interested now in a solution. The solutions I've seen so far have potential, but in my opinion most of them seem like they are more complex, would be more overhead, and produce worse performance

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Sven Barth
Am 08.07.2011 12:05, schrieb Jonas Maebe: However, looking at the generated assembly, I can't believe there isn't a more efficient way to handle the implicit try-finally. It feels to me like that is where the problem is. There is a lot of code and several function calls that go into implementing

Re: [fpc-devel] Const optimization is a serious bug (What nexy)

2011-07-08 Thread Hans-Peter Diettrich
Martin schrieb: c) keep the current behaviour, but add functionality to the compiler to help debug problems that can occur as a result of problems that can occur as a result of this behaviour Concrete: add means to ignore const with managed types. Further debugging aids as far as feasable.

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Den Jean
On Friday 08 July 2011 12:05:02 Jonas Maebe wrote: The main problem here is that FPC's exception handling is based on setjump/longjump. This technique has a relatively high overhead for try, but low overhead when an exception actually occurs (of course, since exceptions are supposed to

[fpc-devel] Sparc v9

2011-07-08 Thread Ludo Brands
membar and stbar are instructions available as of sparc v9. To get fpc running on a sparc v9 I have commented out def_system_macro('FPC_HAS_MEMBAR'); in compiler/options.pas. Is there a command line option that does the same? Ludo ___ fpc-devel

Re: [fpc-devel] Sparc v9

2011-07-08 Thread Vincent Snijders
2011/7/8 Ludo Brands ludo.bra...@free.fr: membar and stbar are instructions available as of sparc v9. To get fpc running on a sparc v9 I have commented out def_system_macro('FPC_HAS_MEMBAR'); in compiler/options.pas. Is there a command line option that does the same? maybe -uFPC_HAS_MEMBAR.

RE : [fpc-devel] Sparc v9

2011-07-08 Thread Ludo Brands
maybe -uFPC_HAS_MEMBAR. Mmm. Didn't expect that a command line undefine would override a define in the code. I'll give it a try. Thanks, Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Sparc v9

2011-07-08 Thread Mark Morgan Lloyd
Ludo Brands wrote: membar and stbar are instructions available as of sparc v9. To get fpc running on a sparc v9 I have commented out def_system_macro('FPC_HAS_MEMBAR'); in compiler/options.pas. Is there a command line option that does the same? I wonder whether this would be worth considering

Re: [fpc-devel] Sparc v9

2011-07-08 Thread Mark Morgan Lloyd
Ludo Brands wrote: membar and stbar are instructions available as of sparc v9. To get fpc running on a 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. I've got one remaining Sun4m system

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Martin
On 09/07/2011 00:09, Max Vlasov wrote: The answer is indirect referencing. it's a workaround that probably will solve the problem, but I must admit that I don't know what is the exact performance price. The compiler when it detects const s: ansistring could switch to passing not the actual

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Max Vlasov
On Sat, Jul 9, 2011 at 3:14 AM, Martin f...@mfriebe.de wrote: On 09/07/2011 00:09, Max Vlasov wrote: The answer is indirect referencing. it's a workaround that probably will solve the problem, but I must admit that I don't know what is the exact performance price. The compiler when it detects

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Martin
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

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Chad Berchek
Martin wrote: - See difference to normal const is that it must be passed by reference. I had not read about it before, but I think constref is a huge step in the right direction. It eliminates my fundamental grief with the current implementation. Specifically, the way const is now defined

Re: [fpc-devel] Const optimization is a serious bug

2011-07-08 Thread Martin
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_