That requires masm to compile the project.
What I actually want is to see the disassembled code from my project (as
Intel Syntax assembly code) to look at how the win32 and win64 code is
optimized and then to fine tune the pascal source.
1. The objdump ("objdump.exe" and "x86_64-win64-objdump
UTF-16 (for
fast per-char access etc optimizations)
Oops, UTF-32, for sure :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I obviously have lot of issues with the RTL suggestions being thrown
around in the past. eg: I have heard lots about the RTL mostly likely
being UTF-16 only, or being spilt into 3 versions AnsiString,
==
How about supporting in the RTL all versions of UCS-2 & UTF-16 (for
fast per-
For example
fpc -Rintel -alr -MObjFPC -Scgi -O1 -Twin32 -Pi386 -g -gl -WG -vewnhi -l
-FuC:\...something... -FuC:\lazarus\lcl\units\i386-win32\win32
-FuC:\lazarus\lcl\units\i386-win32
-FuC:\lazarus\components\lazutils\lib\i386-win32
-FuC:\lazarus\packager\units\i386-win32 -FuC:\...something...
21.08.2012 5:38, ABorka пишет:
Is there a way to see the generated ".s" assembly files as Intel syntax instead of
the AT&T one?
The -Rintel flag does not seem to work, or I am doing something wrong.
Tried command line and fpc.cfg both, on win32 and win64, latest SVN .
-R switch controls parsi
On 8/20/2012 21:38, ABorka wrote:
Is there a way to see the generated ".s" assembly files as Intel syntax instead
of the AT&T one?
The -Rintel flag does not seem to work, or I am doing something wrong.
Tried command line and fpc.cfg both, on win32 and win64, latest SVN .
what command line, exa
Is there a way to see the generated ".s" assembly files as Intel syntax
instead of the AT&T one?
The -Rintel flag does not seem to work, or I am doing something wrong.
Tried command line and fpc.cfg both, on win32 and win64, latest SVN .
___
fpc-devel
Ivanko B schrieb:
No, Unicode is large than UCS-2. Also about your "alien language"
comment. Unicode includes code points not just for spoken languages,
but for anything that can be written. eg: musical notes, scientific
symbols, advanced math symbols, map glyphs, smiley faces (can be used
in
Graeme Geldenhuys schrieb:
{$IFDEF WINDOWS}
UnicodeString = type AnsiString(CP_UTF16);
AnsiStrings consist of bytes only, for good reasons (mostly
performance). The Delphi developers wanted to implement what you
suggest, but dropped that approach later again.
String classes have t
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
I've got a couple of terminal emulators using WideChar and WideString
for internal manipulation, what /should/ I be using? and where does it
leave things like Sorokin's regex unit, which similarly use WideChar
and WideString?
Depends on
MAm 20.08.2012 20:27 schrieb "Hans-Peter Diettrich" :
>
> Graeme Geldenhuys schrieb:
>
>> On 20/08/12 08:52, Sven Barth wrote:
>>>
>>>
>>> Just to avoid confusion: The reference counted 2-byte string type on all
>>> platforms is UnicodeString, not WideString (the latter is not reference
>>> counted
Am 20.08.2012 20:27, schrieb Graeme Geldenhuys:
>
>>> * UnicodeString is always UTF-16 (so everything but Windows takes a
>>> conversion penalty)!
>>
>> A decision has been made and you are not happy with it. Fine. But before
>> you called the fpc team being in a deadlock?
>
> Many things by th
Since the Delphi versions are incompatible amongst each other, how can
a single RTL and compiler mode switch support *all* these versions?
Really the team seems to fights to FPC + Lazarus be capable of
building thousands of Delphi based components - archivers, cyphers,
audio pr
On 20 August 2012 18:42, Hans-Peter Diettrich wrote:
> *only* handle Unicode BMP characters, not surrogate pairs, and you have to
> decide whether this restriction is okay for you.
Such a restriction should NEVER be okay! Otherwise Unicode support is
incomplete. That is what makes UTF-8 so great.
Hi,
On 20 August 2012 17:37, Florian Klämpfl wrote:
>
> True, it's not yet released but in 2.7.1 aka trunk for development,
> testing and bug fixing.
Understood. I'm normally reluctant to try FPC Trunk, but thought that
I better try this time round.
>> * new mode 'delphiunicode' was introduc
Graeme Geldenhuys schrieb:
On 20/08/12 08:52, Sven Barth wrote:
Just to avoid confusion: The reference counted 2-byte string type on all
platforms is UnicodeString, not WideString (the latter is not reference
counted on Windows platforms).
Please correct me if I am wrong, but I think WideStri
Graeme Geldenhuys schrieb:
The "delphi compatibility" is purely a myth too. FPC isn't compatible
with a single Delphi version (except maybe the 10 year old Delphi 7).
For any newer Delphi versions, it has bits of this, bits of that... I
wouldn't call that "compatible".
+1
Since the Delphi v
Mark Morgan Lloyd schrieb:
I've got a couple of terminal emulators using WideChar and WideString
for internal manipulation, what /should/ I be using? and where does it
leave things like Sorokin's regex unit, which similarly use WideChar and
WideString?
Depends on which libraries you use. AFA
Mattias Gaertner schrieb:
I guess most people would say that "good multi language Unicode support
in FPC" requires a Unicode supporting RTL.
Please clarify: *Unicode* or UTF-16 support?
Unicode is covered by both UTF-8 and UTF-16, so it's not really
important which encoding is used in the su
Am 20.08.2012 18:05, schrieb Graeme Geldenhuys:
> Hi,
>
> On 20 August 2012 15:43, Florian Klämpfl wrote:
>> Besides the resourcestrings I'am not aware of any unicodestring issues
>> in the *compiler*. If there are, please report them to the issue tracker.
>
>
> I have heard various back-and-fo
...Continuing the discussion of a Unicode rTL in a new thread as promised...
I obviously have lot of issues with the RTL suggestions being thrown
around in the past. eg: I have heard lots about the RTL mostly likely
being UTF-16 only, or being spilt into 3 versions AnsiString, UTF-16
and UTF-8 (a
Hi,
On 20 August 2012 15:43, Florian Klämpfl wrote:
> Besides the resourcestrings I'am not aware of any unicodestring issues
> in the *compiler*. If there are, please report them to the issue tracker.
I have heard various back-and-forth comments about UnicodeString and
others, which makes me be
Am 20.08.2012 16:25, schrieb Graeme Geldenhuys:
> On 20 August 2012 15:11, Florian Klämpfl wrote:
>> And who implements it? The public votes as well?
>
> Why are you complaining? You have your hobby projects (FPC etc.), and
> I have mine (fpGUI, tiOPF, OnGuard, MPP etc). I have no problem
> contr
No, Unicode is large than UCS-2. Also about your "alien language"
comment. Unicode includes code points not just for spoken languages,
but for anything that can be written. eg: musical notes, scientific
symbols, advanced math symbols, map glyphs, smiley faces (can be used
in in email's, IM prog
This probably explains the difference. MSEgui uses UnicodeString and is
compiled with -Fcutf8 for assignement of Unicode string constants to
UnicodeString variables and transparent conversion of Unicode string
constants to system encoding at runtime.
=
Really. MSEgui doesn't expose a
On 20 August 2012 15:24, Ivanko B wrote:
> Isn't UCS-2 enough for all possible coverage on the Earth planet ?
No, Unicode is large than UCS-2. Also about your "alien language"
comment. Unicode includes code points not just for spoken languages,
but for anything that can be written. eg: musical no
On 20 August 2012 15:11, Florian Klämpfl wrote:
> And who implements it? The public votes as well?
Why are you complaining? You have your hobby projects (FPC etc.), and
I have mine (fpGUI, tiOPF, OnGuard, MPP etc). I have no problem
contributing to something I actually know or (have the time to)
Fine with me: let's kick all those complicated utf-8 and utf-16
=
Isn't UCS-2 enough for all possible coverage on the Earth planet ?
Even chineese people use "64K-" dictionary (the sipmplified alphabet)
for computer typing.
PS:
UCS-4 (and UTF-8 BTW) looks appropriate for future
Am 20.08.2012 10:26, schrieb Graeme Geldenhuys:
>
> So the BIG question remains: When will the FPC team sit down and hash
> out the details of implementing Unicode support? Please note, I'm not
> saying "implement it", just saying... "agree on how it should be
> implemented".
Fine with me: let's
In our previous episode, Graeme Geldenhuys said:
> Yes, I gave FPC 2.7.1 the benefit of the doubt... And what did my
> little experiment prove? That FPC is not nearly compatible enough with
> even a D2009 project - that's a Delphi version that is 4 years old,
> and within a month superseded by yet
On Monday 20 August 2012 14:45:34 Anton Kavalenka wrote:
> On 20.08.2012 15:45, Martin Schreiber wrote:
> > On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
> >> Resources from both Windows and Linux EXE are extracted in UTF-8 (not
> >> win1251).
> >
> > Do you compile with -Fcutf8 or {$cod
On 20.08.2012 15:45, Martin Schreiber wrote:
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
Martin
___
fpc-dev
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
>
> Resources from both Windows and Linux EXE are extracted in UTF-8 (not
> win1251).
>
Do you compile with -Fcutf8 or {$codepage utf8}?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal
On 20.08.2012 14:03, Martin Schreiber wrote:
On Monday 20 August 2012 12:37:24 Anton Kavalenka wrote:
Since the beginning of my FPC use I maintain the following FPC/Delphi
compatible code.
Does it work if the source has been compiled with -Fcutf8 on Windows? IIRC FPC
converts the source utf8 c
On 20 August 2012 11:36, Marco van de Voort wrote:
> I don't agree, and frankly I think it is ridiculous. Compatibility is what
> brought the projects so far (and fact is that you yourself were asking about
> compatibility only a few days ago)
Yes, I gave FPC 2.7.1 the benefit of the doubt... An
On Monday 20 August 2012 12:37:24 Anton Kavalenka wrote:
>
> Since the beginning of my FPC use I maintain the following FPC/Delphi
> compatible code.
>
Does it work if the source has been compiled with -Fcutf8 on Windows? IIRC FPC
converts the source utf8 constants to the system encoding before bu
Graeme Geldenhuys wrote on Mon, 20 Aug 2012:
Get the compiler to decently support Unicode. At least the public
can then build on that however they want. The FPC RTL can then later
be mangled to be a delphi clone - or leave it to other projects to
implement there own RTL's.
At the moment
On 19.08.2012 10:18, Martin Schreiber wrote:
Hi,
In 2008 and 2011 there were threads about FPC and Unicode resource strings
with the conclusion that FPC does not support them.
Are Unicode resource strings implemented in FPC now? I did not find it in
documentation.
Is there a replacement or supple
In our previous episode, Graeme Geldenhuys said:
> The "delphi compatibility" is purely a myth too. FPC isn't compatible
> with a single Delphi version (except maybe the 10 year old Delphi 7).
> For any newer Delphi versions, it has bits of this, bits of that... I
> wouldn't call that "compatibl
On 20/08/12 10:22, Martin Schreiber wrote:
On Monday 20 August 2012 11:10:27 Marco van de Voort wrote:
I'm starting to believe the hard break is the only serious option.
My opinion: Do what you want with RTL and FCL but optimize the compiler so it
is possible to build optimal frameworks for di
On 08/20/2012 10:46 AM, Michael Schnell wrote:
long winding discussion in this forum
.. and on the Lazarus forum ...
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 08/20/2012 11:30 AM, Mark Morgan Lloyd wrote:
for basic two-byte Unicode handling, what types should be used?
:-) *That* is part of the problem :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mail
Jonas Maebe wrote:
Mark Morgan Lloyd wrote on Mon, 20 Aug 2012:
So could somebody make a definitive statement: for basic two-byte
Unicode handling, what types should be used?
unicodestring, because it is generally somewhat faster than widestring
on Windows. On non-Windows platforms, widestri
On Monday 20 August 2012 11:39:34 Mattias Gaertner wrote:
> > Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations
> > which don't need to be strictly Delphi compatible and therefore can
> > better suit the users needs.
>
> Yes, specializations have advantages.
>
> I only thin
Am 20.08.2012 10:26, schrieb Martin Schreiber:
On Monday 20 August 2012 09:52:47 Sven Barth wrote:
Just to avoid confusion: The reference counted 2-byte string type on all
platforms is UnicodeString, not WideString (the latter is not reference
counted on Windows platforms).
WideString was ref
On Mon, 20 Aug 2012 10:56:32 +0200
Martin Schreiber wrote:
> On Monday 20 August 2012 10:35:09 Mattias Gaertner wrote:
>
> > > Thanks Jonas and Paul.
> > > Please permit a little comment. All what was missing for good multi
> > > language Unicode support in FPC after Florian and Peter implemente
Mark Morgan Lloyd wrote on Mon, 20 Aug 2012:
So could somebody make a definitive statement: for basic two-byte
Unicode handling, what types should be used?
unicodestring, because it is generally somewhat faster than widestring
on Windows. On non-Windows platforms, widestring=unicodestring
Graeme Geldenhuys wrote:
On 20/08/12 08:52, Sven Barth wrote:
Just to avoid confusion: The reference counted 2-byte string type on all
platforms is UnicodeString, not WideString (the latter is not reference
counted on Windows platforms).
Please correct me if I am wrong, but I think WideString
On Monday 20 August 2012 11:10:27 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations
> > which don't need to be strictly Delphi compatible and therefore can
> > better suit the users needs.
>
> IM
In our previous episode, Martin Schreiber said:
> Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations
> which don't need to be strictly Delphi compatible and therefore can better
> suit the users needs.
IMHO it is more a question if a hard break like Delphi is necessary or
On Monday 20 August 2012 10:35:09 Mattias Gaertner wrote:
> > Thanks Jonas and Paul.
> > Please permit a little comment. All what was missing for good multi
> > language Unicode support in FPC after Florian and Peter implemented
> > widestrings (which were reference counted on all platforms at the
On 08/20/2012 10:26 AM, Graeme Geldenhuys wrote:
Nobody can agree on anything.
Which is rather understandable (as several a long winding discussion in
this forum showed). FPC is always eager to provide as full Delphi
compatibility as possible, and the Delphi Unicode support is not very
"nice".
On Mon, 20 Aug 2012 06:52:23 +0200
Martin Schreiber wrote:
> On Sunday 19 August 2012 09:41:48 Paul Ishenin wrote:
> > 19.08.12, 15:18, Martin Schreiber wrote:
> > > Hi,
> > > In 2008 and 2011 there were threads about FPC and Unicode resource
> > > strings with the conclusion that FPC does not su
On 20/08/12 08:52, Sven Barth wrote:
Just to avoid confusion: The reference counted 2-byte string type on all
platforms is UnicodeString, not WideString (the latter is not reference
counted on Windows platforms).
Please correct me if I am wrong, but I think WideString was reference
counted an
On Monday 20 August 2012 09:52:47 Sven Barth wrote:
>
> Just to avoid confusion: The reference counted 2-byte string type on all
> platforms is UnicodeString, not WideString (the latter is not reference
> counted on Windows platforms).
>
WideString was reference counted on Windows when it was intro
ABorka wrote on Mon, 20 Aug 2012:
Win32 .exe compiled on Win64 computer, latest SVN build.
I am trying to multiply 2 Integers (Declared as LongInt but
sometimes need to use it as LongWord) and put the result into a
QWord (64bit unsigned) result variable on Win32.
However, it seems that th
Am 20.08.2012 06:52, schrieb Martin Schreiber:
On Sunday 19 August 2012 09:41:48 Paul Ishenin wrote:
19.08.12, 15:18, Martin Schreiber wrote:
Hi,
In 2008 and 2011 there were threads about FPC and Unicode resource
strings with the conclusion that FPC does not support them.
Are Unicode resource s
57 matches
Mail list logo
