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 generator, so that it automatically would support all GCC architectures, but obviously this is not the case :(. Optimization is not a real issue for me. So I suppose it's easier to do a new native FPC code generator, especially as same can be done in Delphi-Language, which is more common in out team. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 to beat. But this task seems to be so difficult that trying to do this was discouraged. :(. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 does on this intermediate code is hard to beat. Just use GPC then? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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-devel
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, no need to learn C), just make it a bounty for say 2000 Eur and I'am sure, somebody will write you a backend for the desired processor. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 http://www.dict.cc/englisch-deutsch/criticism.html What about saying that procedure proc; external 'libname' name 'proc'; denotes a function that's dynamically loaded implicitly, while procedure proc; external name 'proc'; denotes a static linked function. This syntax is not possible. The external 'xxx' name 'proc' is there for a reason, for systems with multiple linker namespaces. Moreover there is already an enormous codebase that uses this. In my opinion that seems like the only logical solution. Explicit dynamic loading will ofcourse still be possible, but you wouldn't need tools or lots of ifdefs You still need to define which functions must be there to start. I'm not aware of how well it would work on Mac platforms, but I'm mostly certain most GNU/Linux and BSD's, and Windows has support for implicit dynamic linking in the executable formats This is ofcourse a solution that would require modification of the compiler, but I think in the long run that it'll make alot of things more comprehensible I don't. I think this dynamically loading of headers has already gone to far. It is a good workaround for a few headers that are versionwise a disaster, like MySQL, but universally, it doesn't solve problems. Offcourse it does. Only with more stable headers you never notice because you never has to change them. Well, that is, after the first convertion to pascal. But as you do this first conversion, this is really usefull. Now, on the contrary, there are 10 different ways to mimic this behaviour, every library uses it's own way. Which is not usefull for the programmer. Besides, it is an optimisation. Oracle for example exports more then 500 functions headers. Those are all initialised at start, maybe 20 are used. Those can be eliminated. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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';
denotes a static linked function.
In my opinion that seems like the only logical solution. Explicit
dynamic loading will ofcourse still be possible, but you wouldn't
need tools or lots of ifdefs
I'm not aware of how well it would work on Mac platforms, but I'm
mostly certain most GNU/Linux and BSD's, and Windows has support for
implicit dynamic linking in the executable formats
What do you mean by implicit dynamic linking?
This is ofcourse a solution that would require modification of the
compiler, but I think in the long run that it'll make alot of things
more comprehensible
It would also require modifications to several existing header
translations, and depending on what implicit dynamic linking means,
it would also make it impossible to use the same unit for static and
for dynamic linking, while this is currently possible. It would also
break backwards compatibility.
Offcourse not. For existing headers nothing changes. For new ones one
can add the 'lazydynamic' keyword or something like that to the
definition.
It it now also impossible to use the same unit for dynamic ans static
loading. This is all done using ifdefs and include files generating two
units sharing the same code. This all stays the same. Or maybe we can
add a flag {$disablelazydynamic} - that way we only need one ifdef.
It has no influence on backwards compatibility.
Joost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 does not have a status register) I suppose I should use the well-tested ARM code generator and modify it appropriately. Once I am done, someone should be able to add some definitions to have the thing create MIPS-32 code. I just need to find the spare time (and at that time, I do hope for appropriate tips from this list to get me started,) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 is the same, but I don't really have an opinion on whether this is actually a good idea (limiting the size for compatibility reason). At least Intel and PowerPC do have atomic operations on smaller sizes. 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 accesses for best performance. PowerPC: pem64, 2005mar, section 5.1.2 says byte, halfword, word, doubleword (64 bit only) are atomic if they are naturally aligned. (word = 32 bits). lwarx/stwcx still exists on 64 bit implementations. So both guarantee smaller reads/writes are atomic. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 'proc'; denotes a function that's dynamically loaded implicitly, while procedure proc; external name 'proc'; denotes a static linked function. In my opinion that seems like the only logical solution. Explicit dynamic loading will ofcourse still be possible, but you wouldn't need tools or lots of ifdefs I'm not aware of how well it would work on Mac platforms, but I'm mostly certain most GNU/Linux and BSD's, and Windows has support for implicit dynamic linking in the executable formats What do you mean by implicit dynamic linking? This is ofcourse a solution that would require modification of the compiler, but I think in the long run that it'll make alot of things more comprehensible It would also require modifications to several existing header translations, and depending on what implicit dynamic linking means, it would also make it impossible to use the same unit for static and for dynamic linking, while this is currently possible. It would also break backwards compatibility. Offcourse not. For existing headers nothing changes. For new ones one can add the 'lazydynamic' keyword or something like that to the definition. The mail I was reacting to, as quoted above, said: *** What about saying thatprocedure proc; external 'libname' name 'proc'; denotes a function that's dynamically loaded implicitly, while procedure proc; external name 'proc'; denotes a static linked function. In my opinion that seems like the only logical solution. Explicit dynamic loading will ofcourse still be possible, but you wouldn't need tools or lots of ifdefs *** That would break backwards compatibility (it would no longer be possible to use a unit with the first syntax for using a statically linked library). You appear to be talking about some different proposal. You're right. I missed that, sorry for that. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 procedure proc; external name 'proc'; denotes a static linked function. In my opinion that seems like the only logical solution. Explicit dynamic loading will ofcourse still be possible, but you wouldn't need tools or lots of ifdefs I'm not aware of how well it would work on Mac platforms, but I'm mostly certain most GNU/Linux and BSD's, and Windows has support for implicit dynamic linking in the executable formats What do you mean by implicit dynamic linking? This is ofcourse a solution that would require modification of the compiler, but I think in the long run that it'll make alot of things more comprehensible It would also require modifications to several existing header translations, and depending on what implicit dynamic linking means, it would also make it impossible to use the same unit for static and for dynamic linking, while this is currently possible. It would also break backwards compatibility. Offcourse not. For existing headers nothing changes. For new ones one can add the 'lazydynamic' keyword or something like that to the definition. The mail I was reacting to, as quoted above, said: *** What about saying thatprocedure proc; external 'libname' name 'proc'; denotes a function that's dynamically loaded implicitly, while procedure proc; external name 'proc'; denotes a static linked function. In my opinion that seems like the only logical solution. Explicit dynamic loading will ofcourse still be possible, but you wouldn't need tools or lots of ifdefs *** That would break backwards compatibility (it would no longer be possible to use a unit with the first syntax for using a statically linked library). You appear to be talking about some different proposal. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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) breaking your selection of 50 free values in Windows range? In that unlikely case, change the range. That raises a question whether incompatibility between two FPC versions 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 use in FPC), this makes 2.6.x and 2.8.x incompatible to each other, right? is better than incompatibility between FPC and Delphi (caused by tight connection between Delphi and one particular platform)... That would be source incompatibility, and therefore much worse. First, this may be the case for compatibility between two FPC versions too. Second, the relation between the numeric values appearing in FPC sources and how the compiler translates the sources to the internal representation in memory (which is possibly only valid for the particular platform) is something that may not be the same (depending on the use cases, of course). Like about 50/280. That's the point of most used. For the less likely ones, define constants to the windows codepages. I don't understand what you mean by define constants to the windows codepages. The 16-bit range is split between a short FPC range and a long Delphi/Windows range. Rarely used codepages use the windows codepage number, and if foreign OSes support that, they must implement a windows2local codepage number conversion. As far as I'm concerned, I'm fine with providing a translation table between Windows codepages and individual platforms (e.g. OS/2), but I'm less comfortable with having to use this translation at runtime under all platforms except for Windows and I'm somewhat worried about not having a solution for supporting character set which may be used e.g. for console on non-windows platforms but are not supported by Windows (have a look at the URL sent by Jonas yesterday for Mac OS X; without having performed complete comparison, it seemed to contain some character sets not listed on the MSDN page for Windows). of certain constants, I can imagine that we should be able to find a gap in the windows character set numbering to cover at least all the character sets registered by IANA. Implementing at all only makes sense if OSes implement them exactly. Several Windows codepages might map to corresponding IANA sets. Do you have some examples of this case? However, we need to provide mapping between the MS Windows character set number and the native character set number for all character set numbers defined in Windows and supported by the particular platform, otherwise the compatibility argument doesn't hold any longer, does it? Just like that you must be able to map the IANA sets to actually supported sets on all platforms. Yes, absolutely. The only potential advantage of IANA numbers would be ensured compatibility across future FPC versions without risk that we need to remap the codepage numbers in the future due to MS or some other vendor changing use of their platform specific constants. I don't say that this is a must or necessarily the best option, just an option we may want to consider depending on the use cases (see below). Note that is all just a guestimate on the size of the free ranges. But I rather not expand that too much. I'm pretty sure that Windows actually support fewer character sets than what is defined in IANA. Since Windows already use word values, there should be fairly large gaps. Looking at the MSDN documentation (http://msdn.microsoft.com/en-us/library/dd317756.aspx), there are 152 values defined altogether and there's currently e.g. just a single value used in the 3 range, no value in 4, nothing between 38 and 436 (probably rather unlikely to change, I'd expect changes rather in other areas), nothing between 1362 and , etc. If the ranges are large enough we can try to fit them in all somewhere. But this means the lesser used codepages are also in twice, blowing up lookuptables or codepages. Yes. Either at compile time (where it makes no difference at all), or possibly also at runtime where this means something like 1600 bytes on 32-bit platforms (assuming 200 records with 2 fields of 4 bytes each). as I understand it, at least console character set information is provided using charset name provided in an environment variable there)? Put them in the table too, for Unix. From certain perspective, these text versions may be useful for all platforms (imagine HTML character set declarations). However, there's a risk that they may not be used completely
Re: [fpc-devel] XML DOM thread safety
2009/11/12 Michael Schnell mschn...@lumino.de: (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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 accesses for best performance. Hmm, note: it seems that intel's movq to move quadword (64bit) register (or load/store data) is usable only for XMM/MMX registers, not the regular registers? This would mean there is no atomic load/store for the native sized regular registers (rax, rcx, etc) in x86_64? Is this right? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 use in FPC), this makes 2.6.x and 2.8.x incompatible to each other, right? I don't see how. Not if the symbolic constants are used, which is the whole point. Note that this is already a slim chance. Specially if the ranges are as big as you say. is better than incompatibility between FPC and Delphi (caused by tight connection between Delphi and one particular platform)... That would be source incompatibility, and therefore much worse. First, this may be the case for compatibility between two FPC versions too. Not if we specify from the start that the RTL predefined symbolic constants are the only supported values, and that the windows codepages _might_ work depending on platform. (e.g. to avoid having too much overhead on embedded targets). IOW numeric values are undefined, but might map to windows codepages if the platform supports it. We have that luxury. The values in Delphi code with windows codepages are already out there, and we have no real power to change that. Sure, you can ultimately convince Delphi open source projects to use FPC valeus and define them for themselves, but is hard, and a problem that you face with each new piece of Delphi code. Again and again. Second, the relation between the numeric values appearing in FPC sources and how the compiler translates the sources to the internal representation in memory (which is possibly only valid for the particular platform) is something that may not be the same (depending on the use cases, of course). Yes, you could lay a xlat layer within the parser. (source number to unicode encoding word mapping) That will break much less code. (only Delphi assembler code), but pulls the lot into the compiler. Not desirable IMHO, and moreover, I'm not convinced there really is a problem that warrants such draconian measures in the first place. and if foreign OSes support that, they must implement a windows2local codepage number conversion. As far as I'm concerned, I'm fine with providing a translation table between Windows codepages and individual platforms (e.g. OS/2), but I'm less comfortable with having to use this translation at runtime under all platforms except for Windows and I'm somewhat worried about not having a solution for supporting character set which may be used e.g. for console on non-windows platforms but are not supported by Windows (have a look at the URL sent by Jonas yesterday for Mac OS X; without having performed complete comparison, it seemed to contain some character sets not listed on the MSDN page for Windows). The lookup only happens at the iconv moment, which is magnitudes more expensive. The example to windows code pages was a bit windows centric, but was only an example. The word to whatever the encoding procedure uses transformation is platform dependant. In the windows case this means a lookup has to be inserted to handle the FPC predefined ones. For other platforms a lookup has to be inserted no matter what. of certain constants, I can imagine that we should be able to find a gap in the windows character set numbering to cover at least all the character sets registered by IANA. Implementing at all only makes sense if OSes implement them exactly. Several Windows codepages might map to corresponding IANA sets. Do you have some examples of this case? I never brought up IANA :-) The point is while IANA might be a standard, the APIs probably don't use IANA numbers as compatibility argument doesn't hold any longer, does it? Just like that you must be able to map the IANA sets to actually supported sets on all platforms. Yes, absolutely. The only potential advantage of IANA numbers would be ensured compatibility across future FPC versions without risk that we need to remap the codepage numbers in the future due to MS or some other vendor changing use of their platform specific constants. I don't say that this is a must or necessarily the best option, just an option we may want to consider depending on the use cases (see below). If you guarantee numeric compatibility for the FPC side. Something I don't plan to do. Only symbolic. (FPC_IANA1_English or whatever. Not the corresponding numeric value) If the ranges are large enough we can try to fit them in all somewhere. But this means the lesser used codepages are also in twice, blowing up lookuptables or codepages. Yes. Either at compile time (where it makes no difference at all), or possibly also at runtime where this means something like 1600 bytes on 32-bit platforms (assuming 200 records with 2 fields of 4 bytes each). And more if the target codepages identifier is a strings yes, less if you can build
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 calling convention is working? I'll be working on a MacOSX 10.5 Intel computer if that makes a difference. It does make a difference. Unfortunately. While working on a patch to add Borland fastcall support to GDB, I discovered that there's a bug in our implementation of Borland fastcall on Mac OS X (although I'm still not sure why). I'll try to fix it tonight and create a test file that you can use. Also, as part of the Mattathias BASIC project, our team leader has almost completed the LLVM-PEG utility for implementing parsing expression grammars in LLVM Assembly. If I end up continuing the work I started on a new LLVM-FPC parser I'll be using that as my tool of choice and implementing the code sections with support routines from LLVM and Clang. (I won't have the liberty of using Clang's libraries in the BASIC compiler since BASIC requires a two- pass compilation process.) That's quite an undertaking! I hope your workload permits you to work on the function calling mechenism soon. Thanks for your advice. Even once this is finished, how do you propose we pass type information from FPC to LLVM libraries? Via strings in LLVM assembler format? (since I've already written that code) Or another way? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 is that UnicodeString gets two new fields: encoding and
char size. However, this information is usually only used if you pass
the string to a RawString parameters. Normal Unicodestring routines
initialize these fields and that's it.
I can confirm there is not much overhead for the new UnicodeString. I was
mislead by the Delphi {$stringchecks on} option and a misinterpreted comment
from a FPC developer that it is not possible to check codepage compatibility
at compiletime, sorry for that.
Some guesswork gained form my experiments with the cpstrnew branch, Win32,
Russian locale, source in utf-8, {$codepage utf8}, please correct me if I am
wrong:
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() of empty string creates CP 1200.
UTF8String
- str:= 'abc'; length(str) = 3, stringcodepage(str) = 65001.
- str:= 'abä'; length(str) = 4, stringcodepage(str) = 65001.
Runtime widestringmanager.Wide2AnsiMoveProc().
- encoding checked by concatenation.
- utf8string:= utf8string + '123' needs conversion to UnicodeString and back.
- setlength() of empty string creates CP 1251.
String1251
- str:= 'abc'; length(str) = 3, stringcodepage(str) = 65001.
- str:= 'abä'; length(str) = 3, stringcodepage(str) = 1251.
Runtime widestringmanager.Wide2AnsiMoveProc().
- str:= 'abc'; str:= str + '123'; needs conversion to UnicodeString and back.
- setlength() of empty string creates CP 1251.
AnsiString
- str:= 'abc'; length(str) = 3, stringcodepage(str) = 65001.
- str:= 'abä'; length(str) = 0, stringcodepage(str) = 1251.
Runtime widestringmanager.Wide2AnsiMoveProc().
- str:= 'abc'; str:= str + '123'; needs conversion to UnicodeString and back.
- setlength() of empty string creates CP 1251.
RawByteString
- str:= 'abc'; length(str) = 3, stringcodepage(str) = 65001.
- str:= 'abä'; length(str) = 0, stringcodepage(str) = 1251.
Runtime widestringmanager.Wide2AnsiMoveProc().
- str:= 'abc'; str:= str + '123'; needs conversion to UnicodeString and back.
- setlength() of empty string creates CP 1251.
- utf8str1:= 'abc'; cp1251str1:= utf8str1; needs conversion to UnicodeString
and back.
- utf8str1:= 'abc'; ansistr1:= utf8str1; no conversion. CP ansistr1 = 65001.
- ansistr1:= 'abc'; utf8str1:= ansistr1; no conversion. CP utf8str1 = 1251.
What are the differences of AnsiString and RawByteString?
Please report when you think cpstrnew branch is stable enough to be tested
with MSEgui.
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Hi Jonas, - Original Message From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC developers' list fpc-devel@lists.freepascal.org 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 discovered that there's a bug in our implementation of Borland fastcall on Mac OS X (although I'm still not sure why). I'll try to fix it tonight and create a test file that you can use. Thanks! Also, as part of the Mattathias BASIC project, our team leader has almost completed the LLVM-PEG utility for implementing parsing expression grammars in LLVM Assembly. If I end up continuing the work I started on a new LLVM-FPC parser I'll be using that as my tool of choice and implementing the code sections with support routines from LLVM and Clang. (I won't have the liberty of using Clang's libraries in the BASIC compiler since BASIC requires a two-pass compilation process.) That's quite an undertaking! LLVM does most of the work with its support routines but I expect that once we get the core language support in (including the ability to extend the language), users will help with writing a few extensions themselves. I hope your workload permits you to work on the function calling mechenism soon. Thanks for your advice. Even once this is finished, how do you propose we pass type information from FPC to LLVM libraries? Via strings in LLVM assembler format? (since I've already written that code) Or another way? There are classes to create any type documented at http://llvm.org/docs/ProgrammersManual.html#Type . As of the current 2.6 release there are now more extensive C bindings included with LLVM than were previously available. Once I get the trunk downloaded I'll see about a link to the actual documentation on how to use those C bindings. Thanks for your help, --Sam ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 extending their use of the codepage values into the range we decided to use in FPC), this makes 2.6.x and 2.8.x incompatible to each other, right? I don't see how. Not if the symbolic constants are used, which is the whole point. Note that this is already a slim chance. Specially if the ranges are as big as you say. OK, I see. That hasn't been my understanding. Still, are we sure that it only has impacts to usability of existing source files and nothing else? Is it really sure that the codepage number is never written into a file when storing the strings? Otherwise compatibility at the level of numeric values may be necessary. is better than incompatibility between FPC and Delphi (caused by tight connection between Delphi and one particular platform)... That would be source incompatibility, and therefore much worse. First, this may be the case for compatibility between two FPC versions too. Not if we specify from the start that the RTL predefined symbolic constants are the only supported values, and that the windows codepages _might_ work depending on platform. (e.g. to avoid having too much overhead on embedded targets). IOW numeric values are undefined, but might map to windows codepages if the platform supports it. I'm not sure if we really manage to get this message through. :-( People who are interested in working at the level of individual codepages would be exactly those who would probably never take care about translating the codepage value (as required by Delphi) into some symbolic constant (not supported by Delphi)... We have that luxury. The values in Delphi code with windows codepages are already out there, and we have no real power to change that. We have the luxury, but we can almost equally well skip this definition of symbolic constants altogether in that case because I suspect that hardly anyone will use them anyway. Still, I'm more concerned in the (unnecessary) runtime overhead. Sure, you can ultimately convince Delphi open source projects to use FPC values and define them for themselves, but is hard, and a problem that you face with each new piece of Delphi code. Again and again. Completely true. Second, the relation between the numeric values appearing in FPC sources and how the compiler translates the sources to the internal representation in memory (which is possibly only valid for the particular platform) is something that may not be the same (depending on the use cases, of course). Yes, you could lay a xlat layer within the parser. (source number to unicode encoding word mapping) That will break much less code. (only Delphi assembler code), but pulls the lot into the compiler. Not desirable IMHO, and moreover, I'm not convinced there really is a problem that warrants such draconian measures in the first place. What draconian measure? Per platform mapping? The translation has much lower impact if performed once at compile time than every time at runtime, right? and if foreign OSes support that, they must implement a windows2local codepage number conversion. As far as I'm concerned, I'm fine with providing a translation table between Windows codepages and individual platforms (e.g. OS/2), but I'm less comfortable with having to use this translation at runtime under all platforms except for Windows and I'm somewhat worried about not having a solution for supporting character set which may be used e.g. for console on non-windows platforms but are not supported by Windows (have a look at the URL sent by Jonas yesterday for Mac OS X; without having performed complete comparison, it seemed to contain some character sets not listed on the MSDN page for Windows). The lookup only happens at the iconv moment, which is magnitudes more expensive. The example to windows code pages was a bit windows centric, but was only an example. The word to whatever the encoding procedure uses transformation is platform dependant. In the windows case this means a lookup has to be inserted to handle the FPC predefined ones. For other platforms a lookup has to be inserted no matter what. Yes. However, possibly at compile time only (if the source files compatibility is the only issue we are concerned about - I'm still not clear about that). of certain constants, I can imagine that we should be able to find a gap in the windows character set numbering to cover at least all the character sets registered by IANA. Implementing at all only makes sense if OSes implement them exactly. Several Windows codepages might map to corresponding IANA sets. Do you have some examples of this case? I never brought up IANA :-) The point is while IANA
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 different
you'll might see is that UnicodeString gets two new fields: encoding and
char size. However, this information is usually only used if you pass
the string to a RawString parameters. Normal Unicodestring routines
initialize these fields and that's it.
I can confirm there is not much overhead for the new UnicodeString. I was
mislead by the Delphi {$stringchecks on} option and a misinterpreted comment
from a FPC developer that it is not possible to check codepage compatibility
at compiletime, sorry for that.
Some guesswork gained form my experiments with the cpstrnew branch, Win32,
Russian locale, source in utf-8, {$codepage utf8}, please correct me if I am
wrong:
I'am not sure how far these things are already fixed/supposed to work.
What are the differences of AnsiString and RawByteString?
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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,DZeroResolution); if (AB) then Result:=((A-B)=Epsilon) else Result:=((B-A)=Epsilon); end; For example 1e-40 and 2e-40 will return TRUE! One possible fix would be: Epsilon:=Max(Abs(A),Abs(B))*DZeroResolution; Also the constants DZeroResolution and EZeroResolution seem to be larger than necessary. Thank you Alain ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
On 12 Nov 2009, at 18:15, Samuel Crow wrote: - Original Message From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC developers' list fpc-devel@lists.freepascal.org 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 discovered that there's a bug in our implementation of Borland fastcall on Mac OS X (although I'm still not sure why). I'll try to fix it tonight and create a test file that you can use. Thanks! Seems like it was my code for GDB under Mac OS X that was wrong, not FPC. Borland fastcall is handled fine under Mac OS X. I've attached the test I've created. To compile: gcc -o tcc tcc.c tgdbcc.s -arch i386 The tcc.c file already includes a test for on of the two functions (and I've verified that it passes if the Pascal functions are compiled with C calling conventinos), but not yet for the other one. They mix a bunch of different parameters, which should provide a good start. I just noticed that I forgot to add in floating point parameters. They are passed in on the stack, and returned in st(0) (regardless of the precision). 80 bits extended is passed in a 12 byte location. The details of the parameter passing are decided in http://svn.freepascal.org/svn/fpc/branches/release_2_2_4_rc1/compiler/i386/cpupara.pas . In particular, check out ti386paramanager.push_addr_param (determines whether a parameter is passed by address or by value), ti386paramanager.create_funcretloc_info (function return location) and ti386paramanager.create_register_paraloc_info (creates the actual parameter and return value locations). The internal compiler identifier for this calling convention is pocall_register. The Pascal test file has been compiled with DWARF debug info. It's been manually stripped down from what the compiler produced to remove dependencies on the RTL. LLVM does most of the work with its support routines but I expect that once we get the core language support in (including the ability to extend the language), users will help with writing a few extensions themselves. Well, just like you prefer writing in C++, most of ours prefer Pascal :) Anyway, we'll see (and it would be nice to get an idea of the kind of performance gains we could get from an LLVM backend). Even once this is finished, how do you propose we pass type information from FPC to LLVM libraries? Via strings in LLVM assembler format? (since I've already written that code) Or another way? There are classes to create any type documented at http://llvm.org/docs/ProgrammersManual.html#Type . As of the current 2.6 release there are now more extensive C bindings included with LLVM than were previously available. Once I get the trunk downloaded I'll see about a link to the actual documentation on how to use those C bindings. Ok. Jonas tcc.c Description: Binary data tgdbcc.pp Description: Binary data tgdbcc.s Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl flor...@freepascal.org 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 with AnsiString as a string type with no encoding (as it's now). Let's assume that the new branche is officially accepted. The library doesn't want the new feature, but it also doesn't want to change its code from AnsiString to RawByteString. Would it be possible to make the following type declaration: unit MainLibTypes; type AnsiString = RawByteString; to avoid using new auto-converters? thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 first I wanted to disagree with you... philosophing about the Pascal
way of doing things, bla, bla...
Pascal has also objects which are no pointers ;)
I know... I know... that might have contributed a bit to my decision to
give up implicit pointers ^^
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/tests/test/cg/obj/
Compiled object files lay in the appropriate sub dir of this dir.
Testing C++ class linking should be done similiar imo.
In theory that is possible, but I found a practical problem: C++ code
requires libstdc++ or at least libsupc++ which implements the new and
delete operators. And to make things worse: this library isn't
available in the Windows release of the compiler... (not a real problem
for me as I'm working on Linux...)
While I could be able to simulate the needed functionality of the
library through Pascal units with correct named procedures/functions, I
don't think that this is the way to go. A better solution (at least for
compiler tests) would be to just compile but not link those test units.
Does the test framework support such an option?
The following is the syntax I'm currently trying to implement:
TMyTestClass = cppclass
procedure MyTestMethod1;
procedure MyTestMethod2; name 'SecondMethod';
end; external 'foolib.so' name 'MyTestClass' namespace 'Foo::Bar';
This corresponds to this C++ class interface:
namespace Foo::Bar {
class MyTestClass {
public:
void MyTestMethod1();
void SecondMethod();
};
}
The external foo name bar-part should be pretty easy (thanks to Jonas'
objc branch which enabled me to find the right spots to include my code
^^ ). The 'name' for methods shouldn't be that complicated, too. But for
namespace support I'll need to introduce a new keyword namespace.
Any comments on this proposal?
Because of the LLVM thread, I think I'll also check the LLVM API to
order the priority of needed features (e. g. virtual methods).
Greetings,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
dmitry boyarintsev schrieb: On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl flor...@freepascal.org 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 with AnsiString as a string type with no encoding (as it's now). 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. Let's assume that the new branche is officially accepted. The library doesn't want the new feature, but it also doesn't want to change its code from AnsiString to RawByteString. Would it be possible to make the following type declaration: unit MainLibTypes; type AnsiString = RawByteString; to avoid using new auto-converters? No, because it would avoid auto-conversion from/to unicodestring as well. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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/tests/test/cg/obj/ Compiled object files lay in the appropriate sub dir of this dir. Testing C++ class linking should be done similiar imo. In theory that is possible, but I found a practical problem: C++ code requires libstdc++ or at least libsupc++ which implements the new and delete operators. And to make things worse: this library isn't available in the Windows release of the compiler... (not a real problem for me as I'm working on Linux...) A lot name mangling etc. can be tested without new/delete: just make the classes static. Further, fpc must be able to create c++ classes on the heap anyways. While I could be able to simulate the needed functionality of the library through Pascal units with correct named procedures/functions, I don't think that this is the way to go. A better solution (at least for compiler tests) would be to just compile but not link those test units. Does the test framework support such an option? Yes, but this is imo a bad idea, better get it running with some hacking. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl flor...@freepascal.org 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 avoid auto-conversion from/to unicodestring as well. does your answer means, that: var r : RawByteString; w : WideString; r:=w; // is impossible because of unknown encoding of RawByteString? thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
dmitry boyarintsev schrieb: On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl flor...@freepascal.org 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 :) 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 ... No, because it would avoid auto-conversion from/to unicodestring as well. does your answer means, that: var r : RawByteString; w : WideString; r:=w; // is impossible because of unknown encoding of RawByteString? No, it is possible becuase the encoding is known because it is stored in RawByteString, but the appropriate conversion will be selected at runtime. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
On Fri, Nov 13, 2009 at 12:55 AM, Florian Klaempfl flor...@freepascal.org 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] tBits
2009/11/11 Dariusz Mazur dar...@emadar.com: 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. If you place enumerators in the same unit as TBits, they will have access to the properted members of TBits. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
