Re: [fpc-devel] Proof of Concept ARC implementation

2014-11-19 Thread Sven Barth
On 20.11.2014 00:08, hinstance wrote: I dunno. Just wanted to see if it is going to work with implicit exceptions turned off. I rather dance around and fix memory leaks when they appear than have implicit try-except block in every procedure. 1. they are try-finally blocks 2. then you'll have to

Re: [fpc-devel] Proof of Concept ARC implementation

2014-11-19 Thread hinstance
I dunno. Just wanted to see if it is going to work with implicit exceptions turned off. I rather dance around and fix memory leaks when they appear than have implicit try-except block in every procedure. I did measurements once; found out that each try-except adds increases stack usage by about

Re: [fpc-devel] Proof of Concept ARC implementation

2014-11-19 Thread Sven Barth
On 19.11.2014 17:29, hinsta...@yandex.ru wrote: Here is the program I've been working on: https://bitbucket.org/hinst/sillychat It was created with purpose of demonstrating how reference-counted objects could be used in a program which actually does something and now it works more or less. And

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Marco van de Voort
In our previous episode, Michael Schnell said: > > But I meant that even if you use utf8string in many places as soon as > > you stuff it in a container like tstringlist, that is gone. (forced > > ansi conversion, since tstringlist's interface is defined using plain > > string(0)) > > AFAI Unde

Re: [fpc-devel] Address size compiler

2014-11-19 Thread Kostas Michalopoulos
Yes this is what i meant. I'd expect that the sizeof(pointer) to return the target architecture's pointer size, not the architecture of the compiler's own executable. On Wed, Nov 19, 2014 at 5:22 PM, Sven Barth wrote: > Am 19.11.2014 16:15 schrieb "Kostas Michalopoulos" < > badsectorac...@gmail.

Re: [fpc-devel] Proof of Concept ARC implementation

2014-11-19 Thread hinsta...@yandex.ru
Here is the program I've been working on: https://bitbucket.org/hinst/sillychatIt was created with purpose of demonstrating how reference-counted objects could be used in a program which actually does something and now it works more or less. And it's beautifulಠ_ಠ Because there are no .Free calls, e

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Sven Barth
Am 19.11.2014 14:46 schrieb "Marco van de Voort" : > > In our previous episode, Sven Barth said: > > Am 19.11.2014 11:39 schrieb "Mattias Gaertner" < nc-gaert...@netcologne.de>: > > > The RTL on Windows now uses the "W" functions and the AnsiString and > > > ShortString are encoded in CP_ACP. Chang

Re: [fpc-devel] Address size compiler

2014-11-19 Thread Sven Barth
Am 19.11.2014 16:15 schrieb "Kostas Michalopoulos" : > > > On Mon, Nov 10, 2014 at 4:07 PM, Michael Van Canneyt < mich...@freepascal.org> wrote: >> >> >> For a cross-compiler, sizeof(pointer) <> sizeof(pointer on target arch) > > > So wait, the following code: > > {$if sizeof(pointer)=8} Code1 {$e

Re: [fpc-devel] Address size compiler

2014-11-19 Thread Jonas Maebe
On 19 Nov 2014, at 16:15, Kostas Michalopoulos wrote: On Mon, Nov 10, 2014 at 4:07 PM, Michael Van Canneyt wrote: For a cross-compiler, sizeof(pointer) <> sizeof(pointer on target arch) So wait, the following code: {$if sizeof(pointer)=8} Code1 {$elseif sizeof(pointer)=4} Code2 {

Re: [fpc-devel] Address size compiler

2014-11-19 Thread Kostas Michalopoulos
On Mon, Nov 10, 2014 at 4:07 PM, Michael Van Canneyt wrote: > > For a cross-compiler, sizeof(pointer) <> sizeof(pointer on target arch) > So wait, the following code: {$if sizeof(pointer)=8} Code1 {$elseif sizeof(pointer)=4} Code2 {$endif} will evaluate Code1 for a FPC compiler that is itself

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Mark Morgan Lloyd
Sergei Gorelkin wrote: 19.11.2014 15:16, Marco van de Voort ?:> In our previous episode, Mark Morgan Lloyd said: introduces a very significant performance overhead;>> Linux also does this. On some but by no means all platforms. I'm specifically trying to>> highlight the fact tha

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Michael Schnell
On 11/19/2014 09:12 AM, Marco van de Voort wrote: But I meant that even if you use utf8string in many places as soon as you stuff it in a container like tstringlist, that is gone. (forced ansi conversion, since tstringlist's interface is defined using plain string(0)) AFAI Understand (having

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Sergei Gorelkin
19.11.2014 15:16, Marco van de Voort пишет: In our previous episode, Mark Morgan Lloyd said: introduces a very significant performance overhead; Linux also does this. On some but by no means all platforms. I'm specifically trying to highlight the fact that on SPARC, Solaris can fix alignment

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Marco van de Voort
In our previous episode, Sven Barth said: > Am 19.11.2014 11:39 schrieb "Mattias Gaertner" : > > The RTL on Windows now uses the "W" functions and the AnsiString and > > ShortString are encoded in CP_ACP. Changing the DefaultSystemCodePage > > to CP_UTF8 does the trick. > > AFAIK we don't use the

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Mattias Gaertner
On Wed, 19 Nov 2014 13:54:00 +0100 Sven Barth wrote: > Am 19.11.2014 11:39 schrieb "Mattias Gaertner" : > > The RTL on Windows now uses the "W" functions and the AnsiString and > > ShortString are encoded in CP_ACP. Changing the DefaultSystemCodePage > > to CP_UTF8 does the trick. > > AFAIK we d

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Jonas Maebe
On 19 Nov 2014, at 13:54, Sven Barth wrote: Am 19.11.2014 11:39 schrieb "Mattias Gaertner" >: The RTL on Windows now uses the "W" functions and the AnsiString and ShortString are encoded in CP_ACP. Changing the DefaultSystemCodePage to CP_UTF8 does the trick. AFAIK we don't use the "W" functi

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Sven Barth
Am 19.11.2014 11:39 schrieb "Mattias Gaertner" : > The RTL on Windows now uses the "W" functions and the AnsiString and > ShortString are encoded in CP_ACP. Changing the DefaultSystemCodePage > to CP_UTF8 does the trick. AFAIK we don't use the "W" functions yet on non-CE Windows. Regards, Sven __

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Jonas Maebe
On 19 Nov 2014, at 12:50, Karoly Balogh (Charlie/SGR) wrote: (On a slightly related note, did anyone run current trunk compiler with cmem allocator through valgrind recently? I seem to get quite some "using uninitialized memory" hits.) I don't know whether it's still the case, but in the

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Mark Morgan Lloyd
Marco van de Voort wrote: Since cmem is documented to be used from the main program file (iow the users code), that would nicely put the responsibility there. That might be where it's imported, but it's heavily used by just about everything when non-scalar types are being shared between a dy

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Marco van de Voort
In our previous episode, Mark Morgan Lloyd said: > >> introduces a very significant performance overhead; > > > > Linux also does this. > > On some but by no means all platforms. I'm specifically trying to > highlight the fact that on SPARC, Solaris can fix alignment issues (at a > price) but L

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Marco van de Voort
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > > > Since the RTL's allocator is documented to align to 16 bytes, it's > > > definitely an issue also with Pascal code. We do have code where also > > > Pascal side triggers the aligment issue, but indeed, the main issue is > > > with

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Mark Morgan Lloyd
Karoly Balogh (Charlie/SGR) wrote: Perhaps the most serious scenario is where an architecture or particular implementation requires alignment, but the kernel traps alignment errors and fixes them silently. SPARC Solaris does this and my understanding is that it introduces a very significant perf

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Karoly Balogh (Charlie/SGR)
Hi, On Wed, 19 Nov 2014, Marco van de Voort wrote: > > Since the RTL's allocator is documented to align to 16 bytes, it's > > definitely an issue also with Pascal code. We do have code where also > > Pascal side triggers the aligment issue, but indeed, the main issue is > > with linked C libs, de

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Karoly Balogh (Charlie/SGR)
Hi, On Wed, 19 Nov 2014, Jonas Maebe wrote: > > Since the RTL's allocator is documented to align to 16 bytes > > Where? Ok, that's actually a very good question. :) I didn't find it anywhere, except some earlier ML/forum posts revealed by Google. However, in practice it still seems to align to

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Marco van de Voort
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > > At least on Linux, malloc() is documented to align to 64 bit on 32 bit and > > > 128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that > > > to 4 bytes and 8 bytes, respectively. > > > > Since cmem is intended for u

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Jonas Maebe
On 19 Nov 2014, at 11:49, Karoly Balogh (Charlie/SGR) wrote: Since the RTL's allocator is documented to align to 16 bytes Where? At least http://www.freepascal.org/docs-html/prog/ progsu173.html only says that the size is rounded up to a multiple of 16/32 bytes; it doesn't say anything abo

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Karoly Balogh (Charlie/SGR)
Hi, On Wed, 19 Nov 2014, Mark Morgan Lloyd wrote: > > At least on Linux, malloc() is documented to align to 64 bit on 32 bit and > > 128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that > > to 4 bytes and 8 bytes, respectively. > > Since cmem is intended for use by FPC, I don'

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Mattias Gaertner
On Wed, 19 Nov 2014 09:22:21 +0100 Jonas Maebe wrote: > On 19/11/14 09:12, Marco van de Voort wrote: > > In our previous episode, Jonas Maebe said: > >>> As Jonas said, not using utf8 on Windows. > >> > >> No, that's not what I said. There is no problem with using UTF-8 on > >> Windows. > > > >

Re: [fpc-devel] CMem allocator memory alignment experiment

2014-11-19 Thread Mark Morgan Lloyd
Karoly Balogh (Charlie/SGR) wrote: Hi, I think there are several issues with the cmem memory allocator. The main issue that it "breaks" the underlying malloc() memory alignment, by adding a four/eight byte size value to the start of each block for the sole reason to be able to throw Runtime Erro

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Jonas Maebe
On 19/11/14 09:12, Marco van de Voort wrote: > In our previous episode, Jonas Maebe said: >>> As Jonas said, not using utf8 on Windows. >> >> No, that's not what I said. There is no problem with using UTF-8 on Windows. > > As long as you explicitely use utf8string. An ansistring with a dynamic c

Re: [fpc-devel] UTF8 RTL

2014-11-19 Thread Marco van de Voort
In our previous episode, Jonas Maebe said: > > As Jonas said, not using utf8 on Windows. > > No, that's not what I said. There is no problem with using UTF-8 on Windows. As long as you explicitely use utf8string. > > A TStringlist with a ansistrings > > in them passed to an RTL routine will b