Re: [fpc-devel] LLVM Backend?

Samuel Crow wrote: GCC already does provide C and C++ (this is a Linux system after all :) ) and I suppose it thus also does provide Objective C and Objective Pascal. I would need FPC ("Delphi Language" Pascal), as I'd like to port a lot of Delphi code. I _HOPED_ LLVM would use the GCC code gene

Re: [fpc-devel] LLVM Backend?

P.S.: In this list, we already did discuss doing an FPC version that creates the intermediate code that can be fed to the GCC code generator. This would make available to FPC all relevant CPU architectures and supposedly the low level optimization that gcc4 does on this intermediate code is hard t

Re: [fpc-devel] XML DOM thread safety

BTW.: Is there a documentation what in the RTL is thread save and what is not (or better: in what way something is/is not thread save, as with multiple functions that work on the same data, some might be thread save, some might be not) ? -Michael ___ fpc

Re: [fpc-devel] LLVM Backend?

Michael Schnell schrieb: > P.S.: > > In this list, we already did discuss doing an FPC version that creates > the intermediate code that can be fed to the GCC code generator. This > would make available to FPC all relevant CPU architectures and > supposedly the low level optimization that gcc4 doe

Re: [fpc-devel] LLVM Backend?

Florian Klaempfl wrote: > Just use GPC then? It does not compile the many thousands of lines of the Delphi project I want to port :(. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-dev

Re: [fpc-devel] LLVM Backend?

Michael Schnell schrieb: > Florian Klaempfl wrote: >> Just use GPC then? > > It does not compile the many thousands of lines of the Delphi project I > want to port :(. Yes, because it's probably very hard to make a (Object) Pascal front end for gcc. Another backend for FPC is 4k-5k lines (pascal,

Re: [fpc-devel] Dynamically Loading Libraries

On Wed, 2009-11-11 at 11:25 +0100, Marco van de Voort wrote: > In our previous episode, Jeppe Johansen said: > > > > > > -Ivo Steinmann > > > > > > > > What about saying that > > procedure proc; external 'libname' name 'proc'; > > denotes

Re: [fpc-devel] Dynamically Loading Libraries

On Wed, 2009-11-11 at 13:21 +0100, Jonas Maebe wrote: > On 10 Nov 2009, at 23:24, Jeppe Johansen wrote: > > > What about saying that > > procedure proc; external 'libname' name 'proc'; > > denotes a function that's dynamically loaded implicitly, while > > procedure proc; external name 'proc';

Re: [fpc-devel] LLVM Backend?

Florian Klaempfl wrote: > I'am sure, somebody > will write you a backend for the desired processor. Yep, a team of three: I, me, and myself. As this processor, a load/store RISC with 32 non-dedicated 32 Bit registers, is very similar to MIPS and thus a bit similar to ARM (only that MIPS-alike it

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Jonas Maebe wrote: If you'd want to limit the length to 2GB on 64 bit systems. I also don't know whether all 64 bit CPUs support atomic operations on 32 bit entities (for the reference count). Something might be said for "compatibility" towards 32 bit implementations that the maximum length i

Re: [fpc-devel] Dynamically Loading Libraries

On Thu, 2009-11-12 at 11:15 +0100, Jonas Maebe wrote: > Joost van der Sluis wrote on do, 12 nov 2009: > > > On Wed, 2009-11-11 at 13:21 +0100, Jonas Maebe wrote: > >> On 10 Nov 2009, at 23:24, Jeppe Johansen wrote: > >> > >> > What about saying that > >> > procedure proc; external 'libname' name

Re: [fpc-devel] Dynamically Loading Libraries

Joost van der Sluis wrote on do, 12 nov 2009: On Wed, 2009-11-11 at 13:21 +0100, Jonas Maebe wrote: On 10 Nov 2009, at 23:24, Jeppe Johansen wrote: > What about saying that > procedure proc; external 'libname' name 'proc'; > denotes a function that's dynamically loaded implicitly, while >

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Thu, November 12, 2009 08:56, Marco van de Voort wrote: > In our previous episode, Tomas Hajny said: >> > > supported codepages in the next version of MS Windows (or that they >> don't >> > > support a different list in some special version, like a version for >> the >> > > Chinese market) break

Re: [fpc-devel] XML DOM thread safety

2009/11/12 Michael Schnell : > (or better: in what way something is/is not thread save, as with > multiple functions that work on the same data, some might be thread > save, some might be not) ? You will find some informations at http://en.wikipedia.org/wiki/Thread_safety -- Inoussa O. ___

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Micha Nelissen wrote: Intel: system programming guide vol 3 section 8.1.1 says byte, word, doubleword, quadword (since Pentium) are all atomic if they are naturally aligned. (word = 16 bits) 8.1.2.2 notes that LOCK is also best to be used on naturally aligned boundaries for 8/16/32/64 bit acces

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

In our previous episode, Tomas Hajny said: > > Incompatibility how exactly? Two different FPC versions are already not > > compatible. > > If you need to change the used range between e.g. FPC 2.6.x and 2.8.x (due > to MS extending their use of the codepage values into the range we decided > to us

Re: [fpc-devel] LLVM Backend?

On 11 Nov 2009, at 23:41, Samuel Crow wrote: I can work on getting Borland Fastcalls implemented in the LLVM x86 backend. By the time I'm done with that we can talk about what else needs doing. Is there a test already in the FPC repository that I can use as a test to make sure that the c

Re: [fpc-devel] Save the current FPC UnicodeString!

On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote: > > > > So please don't destroy this ideal solution by dropping current FPC > > UnicodeString in favour of the Delphi string which is complicated, > > Who says that? If you don't mess with code pages, the only different > you'll might see

Re: [fpc-devel] LLVM Backend?

Hi Jonas, - Original Message > From: Jonas Maebe > To: FPC developers' list > Sent: Thu, November 12, 2009 7:48:58 AM > Subject: Re: [fpc-devel] LLVM Backend? > > -snip- > It does make a difference. Unfortunately. While working on a patch to add > Borland fastcall support to GDB, I

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Thu, November 12, 2009 14:19, Marco van de Voort wrote: > In our previous episode, Tomas Hajny said: >> > Incompatibility how exactly? Two different FPC versions are already >> not >> > compatible. >> >> If you need to change the used range between e.g. FPC 2.6.x and 2.8.x >> (due >> to MS exten

Re: [fpc-devel] Save the current FPC UnicodeString!

Martin Schreiber schrieb: > On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote: >>> So please don't destroy this ideal solution by dropping current FPC >>> UnicodeString in favour of the Delphi string which is complicated, >> Who says that? If you don't mess with code pages, the only diffe

[fpc-devel] function samevalue in unit math of FPC-2.2.4

Hi, the function math.samevalue does not seem to work for small numbers: See FPC-2.2.4 unit math lines 2177, 2155, 2195: function SameValue(const A, B: Double; Epsilon: Double): Boolean; begin if (Epsilon=0) then Epsilon:=Max(Min(Abs(A),Abs(B))*DZeroResolution,DZeroResoluti

Re: [fpc-devel] LLVM Backend?

On 12 Nov 2009, at 18:15, Samuel Crow wrote: - Original Message From: Jonas Maebe To: FPC developers' list Sent: Thu, November 12, 2009 7:48:58 AM Subject: Re: [fpc-devel] LLVM Backend? -snip- It does make a difference. Unfortunately. While working on a patch to add Borland fas

Re: [fpc-devel] Save the current FPC UnicodeString!

On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote: > > What are the differences of AnsiString and RawByteString? > > Ansistring: system encoding System encoding at compile time or run time? ___ fpc-devel maillist - fpc-devel@lists.freepascal

Re: [fpc-devel] Save the current FPC UnicodeString!

Martin Schreiber schrieb: > On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote: >>> What are the differences of AnsiString and RawByteString? >> Ansistring: system encoding > > System encoding at compile time or run time? Runtime, as it is currently.

Re: [fpc-devel] Save the current FPC UnicodeString!

On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl wrote: > Ansistring: system encoding > RawByteString: variable encoding, cannot be checked at compile time, > when working with RawByteStrings, you've to take care of the newly > introduced encoding field Let's say there's a library that works wit

Re: [fpc-devel] First cppclass test

Hi again! Florian Klaempfl schrieb: Sven Barth schrieb: Florian Klaempfl schrieb: Sven Barth schrieb: All in all I have the following goals for (my) future work on this: * make a cppclass an implicit pointer I don't like this idea because C++-classes aren't an implicit pointer either. At f

Re: [fpc-devel] Save the current FPC UnicodeString!

dmitry boyarintsev schrieb: > On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl > wrote: >> Ansistring: system encoding >> RawByteString: variable encoding, cannot be checked at compile time, >> when working with RawByteStrings, you've to take care of the newly >> introduced encoding field > > Le

Re: [fpc-devel] First cppclass test

Sven Barth schrieb: >>> If so, how do you >>> suggest to write those tests, especially as they (currently) rely on a >>> external library... >> >> Libraries or object files? FPC does similiar testing for C linking: the >> C sources are checked in into >> http://svn.freepascal.org/svn/fpc/trunk/test

Re: [fpc-devel] Save the current FPC UnicodeString!

On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl wrote: > Well, an ansistring has an implicit encoding: system. This won't change > and if one uses only unicodestrings and ansistrings, no change will be > noticed. Thanks. It's always nice to hear "No changes required" :) > No, because it would

Re: [fpc-devel] Save the current FPC UnicodeString!

dmitry boyarintsev schrieb: > On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl > wrote: >> Well, an ansistring has an implicit encoding: system. This won't change >> and if one uses only unicodestrings and ansistrings, no change will be >> noticed. > > Thanks. It's always nice to hear "No chang

Re: [fpc-devel] Save the current FPC UnicodeString!

On Fri, Nov 13, 2009 at 12:55 AM, Florian Klaempfl wrote: > Well, I guess you're talking about lazarus ;) I don't see yet however, > if and how the ansistring abuse in the lcl will bite one ... not really. But it's good to know that LCL is safe as well :) thanks, dmitry __

Re: [fpc-devel] Save the current FPC UnicodeString!

Martin Schreiber wrote: UnicodeString - always utf-16 encoded. - str:= 'abc'; length(str) = 6, stringcodepage(str) = 1200. - str:= 'abä'; length(str) = 6, stringcodepage(str) = 1200. - no encoding checks by concanteation, concatenation does not work because of wrong length() value. - setlength(

Re: [fpc-devel] [patch] tBits

2009/11/11 Dariusz Mazur : > >  With this I have and question: >  For me function FindNextRaw should be in protected section >  But then we cant use them in enumerator, except when something like friend > classes can be used in FPC. >  I only read about this concept, is it possible/plan  in FPC. I