Op Sun, 18 Sep 2011, schreef Torsten:
I do not know exactly which functions need to be changed. I'm hoping for tips.
You will have to be a bit exploring here; AVX is a major upgrade to the
x86 instruction set, and there will likely not be a few routines that need
to be changed.
First ste
Joost van der Sluis wrote / napísal(a):
On Sat, 2011-09-17 at 10:56 +0200, Michael Van Canneyt wrote:
On Sat, 17 Sep 2011, Martin Schreiber wrote:
Hi,
TField.SetData() in fixes_2_6 calls TField.Validate().
2.4.4 does not, trunk neither.
Strange that 2.6 does this if trunk does
On Sun, Sep 18, 2011 at 11:45 AM, Jonas Maebe wrote:
>
> On 18 Sep 2011, at 13:57, Flávio Etrusco wrote:
>
>> One obvious way to mitigate this would be to store the last
>> CodePoint->Char in the string record, so that at least the most common
>> case is covered.
>
> ... and so that the common cas
Luiz Americo Pereira Camara schrieb:
Thanks, but that's nothing new to me in general, and the RawByteString
handling doesn't work as documented.
procedure ShowCodePage(const S: RawByteString);
begin
Form1.Caption := IntToStr(StringCodePage(S));
end;
Strange
What value you get passing and
On 18/9/2011 17:04, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
Can you give me a link? I checked the XE documentation and RTL, and
could not find that RawByteString can hold UTF-16, and my test
confirms that:
http://edn.embarcadero.com/article/38980
You may read also
Am 18.09.2011 11:02, schrieb Florian Klämpfl:
Am 18.09.2011 10:54, schrieb Torsten:
Hi,
im starting with implementation of AVX (Intel/AMD) in fpc-assemblercode.
I use in first step a external assembler (linux "as"). In this case, it
is easy to use XMM-Register (max. 3 parameter) (only change t
2011/9/18 Marco van de Voort :
> I do most of the merging, but I don't merge compiler revs unless I get a
> green light from the compiler devs.
OK.
I see maybe this question only Florian can answer, because he made the
commit, and maybe he's simply too busy. That's fine. I hope he can
read it befo
Luiz Americo Pereira Camara schrieb:
Can you give me a link? I checked the XE documentation and RTL, and
could not find that RawByteString can hold UTF-16, and my test
confirms that:
http://edn.embarcadero.com/article/38980
You may read also:
http://www.micro-isv.asia/2008/08/using-rawbyt
DaWorm schrieb:
On Sun, Sep 18, 2011 at 12:01 PM, Sven Barth
wrote:
On 18.09.2011 17:48, DaWorm wrote:
But isn't it O(n^2) only when actually using unicode strings?
All MBCS encodings, with no fixed character size, suffer from that problem.
Wouldn't you also be able to do something like S
2011/9/18 Marco van de Voort :
> The trouble is that it is not that easy, consider the first thing a
> long time pascal user will do is fix his existing code which has many
> constructs that loop over a string:
>
> setlength(s2,s1);
> for i:=1 to length(s1) do
> s2[i]:=s1[i];
>
> Now, to return c
In our previous episode, DaWorm said:
> But isn't it O(n^2) only when actually using unicode strings?
> Wouldn't you also be able to do something like String.Encoding := Ansi
> and then all String[i] accesses would then be o(n) + x (where x is the
> overhead of run time checking that it is safe to
On Sun, Sep 18, 2011 at 12:01 PM, Sven Barth
wrote:
> On 18.09.2011 17:48, DaWorm wrote:
But isn't it O(n^2) only when actually using unicode strings?
Wouldn't you also be able to do something like String.Encoding := Ansi
and then all String[i] accesses would then be o(n) + x (where x is the
over
On 18.09.2011 17:48, DaWorm wrote:
On Sep 18, 2011 5:50 AM, "Marco van de Voort" mailto:mar...@stack.nl>> wrote:
>
> The trouble is that it is not that easy, consider the first thing a
> long time pascal user will do is fix his existing code which has many
> constructs that loop over a stri
In our previous episode, DaWorm said:
> >
> > So instead of O(n) this loop suddenly becomes O(n^2)
>
> Sure it does. So what?
So much!
> The point is, it will do what the user expects.
No it doesn't. The user has no clue, and will just stumble on the next
detail (like codepoints not being
On Sep 18, 2011 5:50 AM, "Marco van de Voort" wrote:
>
> The trouble is that it is not that easy, consider the first thing a
> long time pascal user will do is fix his existing code which has many
> constructs that loop over a string:
>
> setlength(s2,s1);
> for i:=1 to length(s1) do
> s2[i]:=s1
On 18 Sep 2011, at 14:34, Martin wrote:
> Does -gv :
> - force either stabs or dwarf
-gv by itself enables the default debug format, just like -g, -gh, -gt, -gc, ...
> - work with both, and add extend info (never mind if stabs or dwarf)
It works with both.
> - observe stabs or dwarf setting (
On 18 Sep 2011, at 13:57, Flávio Etrusco wrote:
> One obvious way to mitigate this would be to store the last
> CodePoint->Char in the string record, so that at least the most common
> case is covered.
... and so that the common case is broken in multithreaded environments.
Directly indexing a
In our previous episode, cobines said:
>
> Can the commit nr 18230 be merged into FPC 2.6 ?
>
> Thanks in advance, simple yes or no will suffice.
I do most of the merging, but I don't merge compiler revs unless I get a
green light from the compiler devs.
_
Sorry, I want to repeat the question because I didn't get any answer
and I would really like to know if the whole 2.6.x line will have this
bug or only 2.6.0, so that I can either skip 2.6.0 or discuss
switching to DWARF.
Can the commit nr 18230 be merged into FPC 2.6 ?
Thanks in advance, simple
On 18/9/2011 10:07, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
On 17/9/2011 11:46, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
The codepage of a RawByteString at runtime will keep the previous
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to c
Trying to improve the lazarus user-interface for selecting what debug
info to generate, I try to understand the relations between settings.
(as for example, indicating to the user, that -gl causes the same debug
info than -g does)
Valgrind requires debug info too so -g-v is nonsnes.. It also un
Luiz Americo Pereira Camara schrieb:
On 17/9/2011 11:46, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
The codepage of a RawByteString at runtime will keep the previous
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the
RawbyteString CodePage (65535) as a
Op Sun, 18 Sep 2011, schreef Florian Klämpfl:
I'am not sure if the ymm registers should be an own register class.
After all, they are a superset of xmm
Exactly. Since if xmm0 is allocated, ymm0 is allocated too; the register
allocator should treat them as a single register. xmm0 and ymm0 ar
On Sun, Sep 18, 2011 at 6:50 AM, Marco van de Voort wrote:
> In our previous episode, Fl?vio Etrusco said:
>>
>> That's somewhat what I was thinking. Actually something like
>>
>> UnicodeString = object
>> (...)
> Such ability is not unique for an object. One can also do something like
> that
On 18.09.2011 13:20, Jonas Maebe wrote:
On 18 Sep 2011, at 13:16, Graeme Geldenhuys wrote:
And it boggles the mind why something so broken / incomplete was
merged into Trunk in the first place?
Yes, we suck from time to time (in this case: testsuite runs were performed,
but the sync and mer
On 18 Sep 2011, at 13:16, Graeme Geldenhuys wrote:
> And it boggles the mind why something so broken / incomplete was
> merged into Trunk in the first place?
Yes, we suck from time to time (in this case: testsuite runs were performed,
but the sync and merge were done by a person who only had ac
On 18/09/2011, Sven Barth wrote:
>
> Currently the POSIX-based systems seem to be broken (the Windows ones
> work). That is already known. The other devs are working on that.
And it boggles the mind why something so broken / incomplete was
merged into Trunk in the first place? Isn't that the whol
On Sunday 18 September 2011 12.44:26 Jonas Maebe wrote:
> On 18 Sep 2011, at 12:26, Sven Barth wrote:
> > For now you can apply the following patch as a workaround. The compiler
> > (and fpmake) will depend on the C-library then (which should not be the
> > case in the final solution).
>
> Not onl
On 18 Sep 2011, at 12:26, Sven Barth wrote:
> For now you can apply the following patch as a workaround. The compiler (and
> fpmake) will depend on the C-library then (which should not be the case in
> the final solution).
Not only that: even with cwstring (and under Windows) the result is wro
On 18.09.2011 11:27, Martin Schreiber wrote:
On Sunday 18 September 2011 10.50:26 Sven Barth wrote:
Well... you can now take a look at trunk as well, because the changes
from cpstrnew have been merged yesterday.
[...]
make[7]: Entering directory `/home/mse/packs/standard/svn/fp/trunk/rtl/linu
In our previous episode, Fl?vio Etrusco said:
>
> That's somewhat what I was thinking. Actually something like
>
> UnicodeString = object
> strict private
> FEncoding: Integer;
> FBuffer: AnsiString;
> function GetCodePointAt(AIndex: SizeInt): Integer;
> procedure SetCodePoint
On 18.09.2011 11:27, Martin Schreiber wrote:
On Sunday 18 September 2011 10.50:26 Sven Barth wrote:
Well... you can now take a look at trunk as well, because the changes
from cpstrnew have been merged yesterday.
[...]
make[7]: Entering directory `/home/mse/packs/standard/svn/fp/trunk/rtl/linu
On Sunday 18 September 2011 10.50:26 Sven Barth wrote:
>
> Well... you can now take a look at trunk as well, because the changes
> from cpstrnew have been merged yesterday.
>
[...]
make[7]: Entering directory `/home/mse/packs/standard/svn/fp/trunk/rtl/linux'
/home/mse/packs/standard/svn/fp/trunk/
Am 18.09.2011 10:54, schrieb Torsten:
> Hi,
>
> im starting with implementation of AVX (Intel/AMD) in fpc-assemblercode.
>
> I use in first step a external assembler (linux "as"). In this case, it
> is easy to use XMM-Register (max. 3 parameter) (only change the file
> "x86ins.dat", examble:
>
>
Hi,
im starting with implementation of AVX (Intel/AMD) in fpc-assemblercode.
I use in first step a external assembler (linux "as"). In this case, it
is easy to use XMM-Register (max. 3 parameter) (only change the file
"x86ins.dat", examble:
[VMOVDQA]
(Ch All, Ch None, Ch None)
xmmreg, xmmrm
On 18.09.2011 02:22, Flávio Etrusco wrote:
On Sat, Sep 17, 2011 at 10:59 AM, DaWorm wrote:
This might be total crap, so bear with me a moment, In an object like
a Stringlist, there is a default property such as Strings, such that
List.Strings[1] is equivalent to List[1], is there not? If, as
36 matches
Mail list logo
