Re: [fpc-devel] TFPHashList (Was: Alternative parsers)
W dniu 2010-10-23 23:04, Florian Klämpfl pisze: Second: when I review assembler list I've notice some strange lines (all optimizations are enabled): Which compiler version? 2.4.x? I think r15502 in trunk should fix this. 2.5.1 but older. Now I test from current. Its better (faster) but I found other strange: first: dec(i) is translate to three lines movl%esi,%eax decl%eax movl%eax,%esi why not simple decl %esi ? Yes. I saw this too and I didn't find the cause, especially because I were not able to reproduce it in a small example. attached before uhlm.pas is too long? its form fpHash When variable is in %ebx things are the same. second if I have: while ii>0 do begin ; dec(ii); assembler look: # [121] while ii>0 do begin jmp.Lj16 //< here add first test of ii .balign 4,0x90 .Lj15: .Ll8: # [122] result:=LongWord(result *8010817 ) xor (Pw^); .Ll10: # [124] dec(ii); movl%esi,%eax decl%eax movl%eax,%esi .Lj16: testl%esi,%esi//<-- this can be avoid, because test from DECL jg.Lj15 Is this possible to achieve this optimizations, If yes, can somebody help, from which file I should start Replacing the jmp by a test and jz is two-fold: it increases code size (thus higher code cache pollution) and it pollutes the branch prediction unit while an uncoditional jump is very cheap on modern processers. You don't understand me My proposition is moving one instruction, outside loop # [121] while ii>0 do begin testl%esi,%esi//<-- this should be added, because after .Lj16 test is absent jmp.Lj16 // jmp not change ZF .balign 4,0x90 .Lj15: .Ll8: # [122] result:=LongWord(result *8010817 ) xor (Pw^); .Ll10: # [124] dec(ii); decl%esi .Lj16: jg.Lj15 // ZF is setting by decl (first timie by testl) -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] crosscompile x64->i386 Ubuntu 10.10 Maverick, latest svn
Am 2010-10-22 22:49, schrieb Lukas Gradl: Hello! I'm still stuck with cross-compiling fpc from x64 to i386 on an Ubuntu 10.10 machine. Compared a compile on Ubuntu 10.10 to one at 10.04. It seems like there ist a problem with environment-variables on my 10.10 - Installation. On 10.10 after a "make all CPU_TARGET=i386" i get: make OS_TARGET= CPU_TARGET= CROSSBINDIR= BINUTILSPREFIX= CROSSCYCLEBOOTSTRAP=1 rtlclean rtl whereas on 10.04 I get: make OS_TARGET=linux CPU_TARGET=x86_64 CROSSBINDIR= BINUTILSPREFIX= CROSSCYCLEBOOTSTRAP=1 rtlclean rtl Please, anyone a hint what might go wrong? Regards Lukas -- -- software security networks Lukas Gradl Eduard-Bodem-Gasse 5 A - 6020 Innsbruck Tel: +43-512-214040-0 Fax: +43-512-214040-21 -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPHashList (Was: Alternative parsers)
Am 23.10.2010 22:46, schrieb Dariusz Mazur: > W dniu 2010-10-22 23:30, Florian Klämpfl pisze: >> Am 22.10.2010 23:17, schrieb Dariusz Mazur: >>> full source in attachment (should I prepare it different?) >> The best would be a diff against compiler sources. > > OK. First I find better computing of hash. My is slight worse than > current (but overall faster) > >>> Second: when I review assembler list I've notice some strange lines (all >>> optimizations are enabled): >>> >> Which compiler version? 2.4.x? I think r15502 in trunk should fix this. > 2.5.1 but older. Now I test from current. Its better (faster) but I > found other strange: > > first: dec(i) is translate to three lines > movl%esi,%eax > decl%eax > movl%eax,%esi > > why not simple decl %esi ? Yes. I saw this too and I didn't find the cause, especially because I were not able to reproduce it in a small example. > When variable is in %ebx things are the same. > > > second if I have: > while ii>0 do begin > ; >dec(ii); > > > assembler look: > > > # [121] while ii>0 do begin > jmp.Lj16 //< here add first test of ii > .balign 4,0x90 > .Lj15: > .Ll8: > # [122] result:=LongWord(result *8010817 ) xor (Pw^); > .Ll10: > # [124] dec(ii); > movl%esi,%eax > decl%eax > movl%eax,%esi > .Lj16: > testl%esi,%esi//<-- this can be avoid, because test from DECL > jg.Lj15 > > > Is this possible to achieve this optimizations, > If yes, can somebody help, from which file I should start > Replacing the jmp by a test and jz is two-fold: it increases code size (thus higher code cache pollution) and it pollutes the branch prediction unit while an uncoditional jump is very cheap on modern processers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPHashList (Was: Alternative parsers)
W dniu 2010-10-22 23:30, Florian Klämpfl pisze: Am 22.10.2010 23:17, schrieb Dariusz Mazur: full source in attachment (should I prepare it different?) The best would be a diff against compiler sources. OK. First I find better computing of hash. My is slight worse than current (but overall faster) Second: when I review assembler list I've notice some strange lines (all optimizations are enabled): Which compiler version? 2.4.x? I think r15502 in trunk should fix this. 2.5.1 but older. Now I test from current. Its better (faster) but I found other strange: first: dec(i) is translate to three lines movl%esi,%eax decl%eax movl%eax,%esi why not simple decl %esi ? When variable is in %ebx things are the same. second if I have: while ii>0 do begin ; dec(ii); assembler look: # [121] while ii>0 do begin jmp.Lj16 //< here add first test of ii .balign 4,0x90 .Lj15: .Ll8: # [122] result:=LongWord(result *8010817 ) xor (Pw^); .Ll10: # [124] dec(ii); movl%esi,%eax decl%eax movl%eax,%esi .Lj16: testl%esi,%esi//<-- this can be avoid, because test from DECL jg.Lj15 Is this possible to achieve this optimizations, If yes, can somebody help, from which file I should start -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
I did get a chance to test it and so far, though I haven't tried all my custom data types supported in my API, I was able to get my Int64 Array to read and write via this new version. So far so good. Thanks again! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
Parameter binding on update sql appears to be working. I traced into Taking a 24 element array of Int64 yields 192 bytes. The size of the data was 193 (always adding 1 byte to the packet). On Reading I presently only get a 1 byte so it's not enough to read in an actual element of int64 to see if we're even close. Checking the DataLength for that record.field yields... Gotta do more work to find length of field... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bitpacked Record Bug
Am 23.10.2010 14:47, schrieb Willibald Krenn: BTW: Changing is_packed_record to in nutils.pas (~ 1155) subscriptn: result:= is_packed_record_or_object(tsubscriptnode(n).left.resultdef) and ( (tsubscriptnode(n).vs.vardef.packedbitsize mod 8 <> 0) or (tsubscriptnode(n).vs.fieldoffset mod 8 <>0)); (tsubscriptnode(n).vs.fieldoffset mod 8 <> 0) or (tsubscriptnode(n).vs.vardef.packedbitsize mod 24 = 0)); seems to fix the problem on x64. Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
On Sat, 23 Oct 2010, Martin Schreiber wrote: On Saturday, 23. October 2010 13.11:01 Michael Van Canneyt wrote: On Fri, 22 Oct 2010, Andrew Brunner wrote: Looking to get some resolution to an immediate problem with postgres component I have... Field definitions for blob can be mapped to bytea and enable support for blob data as I am pretty sure byte for byte output/input would suffice. Some debugging may be needed to make sure we don't need escape/unescape on string literals. I'm hoping for a quick fix. I committed a fix in 16203, please test. Please don't forget to mark bytea parameters as binary or use hex notation, otherwise the data probably will be cut by the first zero or even not accepted because of encoding errors. Thanks for the tip. Done in rev. 16207, had a sneak peak at your implementation for it. (I don't use postgres myself, so any testing will be welcome) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bitpacked Record Bug
Hi! I stumbled accross a bug in fpc that manifests itself when working with bitpacked records that have fields with pos and size mod 8 == 0; For example: type TField = bitpacked record case boolean of true: (value : integer); false: ( data: 0 .. $FF; // 24 bits operation: 0 .. $7F;// 7 bits binop: Boolean // one bit ) end; var a, b: integer; instr: TField; begin //instr.value := $0104; a := instr.data ; //and $FF; // bug in fpc b := instr.data + 1; end. will generate asm like mov0x37ab3(%rip),%eax# 0x439020 mov%eax,0x37a8d(%rip)# 0x439000 mov0x37aa7(%rip),%eax# 0x439020 and$0xff,%rax and$0x,%eax inc%rax which is wrong for the first assignment and not very clever for the second one. I've tracked the issue down to the following check in ncv.pas: ncv.pas (~ 265) if equal_defs(p.resultdef,def) and not is_bitpacked_access(p) then p.resultdef:=def The function is_bitpacked_access (relevant parts) is defined as follows. in nutils.pas (~ 1155) subscriptn: result:= is_packed_record_or_object(tsubscriptnode(n).left.resultdef) and ( (tsubscriptnode(n).vs.vardef.packedbitsize mod 8 <> 0) or (tsubscriptnode(n).vs.fieldoffset mod 8 <>0)); Now, my question is why is an access with a size mod 8 and an offset mod 8 considered NOT bitpacked? Or is the code in ncv.pas to blame? Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
Updating and testing... Thanks Martin and Michael ! > I committed a fix in 16203, please test. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
On Saturday, 23. October 2010 13.11:01 Michael Van Canneyt wrote: > On Fri, 22 Oct 2010, Andrew Brunner wrote: > > Looking to get some resolution to an immediate problem with postgres > > component I have... > > > > Field definitions for blob can be mapped to bytea and enable support > > for blob data as I am pretty sure byte for byte output/input would > > suffice. Some debugging may be needed to make sure we don't need > > escape/unescape on string literals. I'm hoping for a quick fix. > > I committed a fix in 16203, please test. > Please don't forget to mark bytea parameters as binary or use hex notation, otherwise the data probably will be cut by the first zero or even not accepted because of encoding errors. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
On Fri, 22 Oct 2010, Andrew Brunner wrote: Looking to get some resolution to an immediate problem with postgres component I have... Field definitions for blob can be mapped to bytea and enable support for blob data as I am pretty sure byte for byte output/input would suffice. Some debugging may be needed to make sure we don't need escape/unescape on string literals. I'm hoping for a quick fix. I committed a fix in 16203, please test. As is right now, the postgres DBMS system if offline limits b/c I happen to rely heavliy on Field/Paramter).AsBlob:=[] in my code for arrays[n] of Int64 where each element is 8 bytes long. MySQL did this flawlessly. What's it gonna take to remove the restriction and map the field to bytea? Well, a 'please' usually does it in this part of the world. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc servers down?
On Sat, 23 Oct 2010, Felipe Monteiro de Carvalho wrote: It seams that www.freepascal.org and our subversion are down. It has been fixed meanwhile. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc servers down?
It seams that www.freepascal.org and our subversion are down. thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte
On Friday, 22. October 2010 22.40:55 Andrew Brunner wrote: > Looking to get some resolution to an immediate problem with postgres > component I have... > Have a look to MSEgui lib/common/db/mpqconnection.pp, it supports blobs by mapping to bytea. http://developer.berlios.de/projects/mseide-msegui/ (server seems to be down at the moment) or http://sourceforge.net/projects/mseide-msegui/ Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
