You are not logged in.
Pages: 1
Is there a SynPDF for 64 bit planned? I am thinking about the assembler part which won't work on 64 bit platforms.
Offline
All asm parts have their own version in pure pascal.
All our source code was designed to be 64 bit ready, since the beginning.
See for instance http://synopse.info/forum/viewtopic.php?id=86
I don't have access to the 64 bit beta program from Embarcadero: they didn't accept my candidature...
But I think making the SynPDF unit completely working with the 64 bit version of Delphi will not be difficult, when the corresponding IDE will be released.
Offline
All asm parts have their own version in pure pascal.
Unfortunately some functions in SynCommon and SynLz etc. (used by SynPDF) have no PurePascal parts.
Offline
Offline
RalfS wrote:Unfortunately some functions in SynCommon and SynLz etc. (used by SynPDF) have no PurePascal parts.
Which functions?
Even SynLZ has a pure pascal version for the compression/decompression.
SynLz:
SynLZcompress1asm
SynLZdecompress1asm
SynCommons:
CopyArray
SynRtlUnwind
TsynLog_Release
....
Offline
SynLZcompress1asm
SynLZdecompress1asm
There is SynLZcompress1pas and SynLZdecompress1pas.
I've updated the source to use the right version, depending on the PUREPASCAL.
SynCommons:
CopyArray
SynRtlUnwind
TsynLog_Release
....
CopyArray is just a small wrapper, but it will rely on the RTL implemented in the 64 bit version of Delphi. I don't know yet how it will be.
And due to the symbol linking layout of the RTL, it can't be written in pascal. The _CopyArray function of System.pas just not available in pascal code, just in asm code...
You are right, the logging and exception handling are still asm dependent.
Because they are also dependent of the RTL implementation by Embarcadero.
This is the only part which does not have a PUREPASCAL version, because it impossible to know (yet) how it should be written. It will certainly be written in 64 bit asm.
And since logging is not mandatory for SynPDF (or even our ORM), we could just get rid of it via a conditional define.
But as I stated, all other code is 64 bit ready, even if not 64 bit approved.
I'm a bit afraid of the upcoming 64 bit compiler performance.
For the floating point (double) computation, it could be faster, since it would use SSE2.
But for the general computation, it could be slower, because less optimized.
For instance, the Free Pascal 64 Bit compiler is two to three times slower than the 32 bit version.
For SynPDF and SynCommons, the 64 bit conversion will be very easy and fast...
So far, so good...
When the 64 bit compiler will be available...
Offline
And since logging is not mandatory for SynPDF (or even our ORM), we could just get rid of it via a conditional define.
Yes. I would like a solution with Defines. I wolud also like a One-File-Solution for SynPDF.pas, as far as possible.
Offline
I wolud also like a One-File-Solution for SynPDF.pas, as far as possible.
This was the fact for the first version of SynPDF: one stand-alone unit, just like SynCrtSock.
But I added a link to SynCommons, because SynPDF tended to have a lot of low-level code in common with SynCommons. And thanks to Delphi smart-linking, only the needed part of SynCommons is linked to the exe.
SynCommons has integrated regression tests, which profit also to SynPDF.
I don't feel unconfortable having SynCommons common to all our Open Source projects.
Optimized UTF-8/Unicode handling, low-level functions and classes tested under Delphi 5 up to XE, do make sense to me. Think of SynCommons as a SysUtils on steroids... (if SysUtils is not a "she").
Offline
Pages: 1