Hi, Przemek
> An now I compared BCC-5.5 and GCC-4.3.1 assembler code generated for
> such modified HVM and this simple code:
>
> void func( void )
> {
> hb_stackPush();
> hb_stackPop();
> }
GCC generates wonderfull code
In my experience BCC produces best code by changing, say
#d
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> Seems like a good idea. Considering the few CRTL stuff we use,
> maybe we could just get rid of them all. At least as far as core is
> concerned. [ Clipper did it, too. ]
Some function like memcpy() or memmove() are very often inlined
and h
Szakáts Viktor wrote:
>
>
> Question, what to do with sqlite3.c.
>
> Brgds,
> Viktor
>
>
I thinks authors of sqlite know this bug
#if defined(SQLITE_TEST) || defined(SQLITE_DEBUG) ||
defined(SQLITE_MEMDEBUG)
/*
** A version of printf() that understands %lld. Used for debugging.
** The p
Hi Przemek,
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
I've already did it, but it's the best if you take a second look
(I can make a mistake virtually anywhere :)
You made exactly what I did with the byte precision ;-)
so after svn update I do not have any conflicts and hbdefs.h
is not mar
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
> I've already did it, but it's the best if you take a second look
> (I can make a mistake virtually anywhere :)
You made exactly what I did with the byte precision ;-)
so after svn update I do not have any conflicts and hbdefs.h
is not marked as modified
Przemek,
I do not know details for MinGW TLS but it's possible that it will be
imporved yet in the future, f.e. now thay can use simple function call
like in BCC. Anyhow in current SVN code the cost of TLS is quite
efficient hidden by HB_STACK_PRELOAD. Just try to remove:
#define HB_STACK_PRE
I've already did it, but it's the best if you take a second look
(I can make a mistake virtually anywhere :)
Question, what to do with sqlite3.c.
Brgds,
Viktor
On 2008.09.25., at 22:12, Przemyslaw Czerpak wrote:
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
I've found some pages li
Szakáts Viktor wrote:
>
>> Gives me:
>> TEST NUMBER = [705032704]
>
#include
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n",50LL );
printf( "TEST NUMER = [%I64u]\n", 50LL );
return 0;
}
http://www.nabble.com/long-l
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> I've found some pages listing %lld as one the significant
> incompatibilities of MinGW compared to Linux GCC.
> In MinGW the equivalent formatting seems to be:
> "%I64d" which is also claimed to be the Microsoft C compatible syntax.
> Testin
On Thu, Sep 25, 2008 at 9:44 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> I've found some pages listing %lld as one the significant
> incompatibilities of MinGW compared to Linux GCC.
>
> In MinGW the equivalent formatting seems to be:
> "%I64d" which is also claimed to be the Microsoft C compa
Hi Przemek,
I've found some pages listing %lld as one the significant
incompatibilities of MinGW compared to Linux GCC.
In MinGW the equivalent formatting seems to be:
"%I64d" which is also claimed to be the Microsoft C compatible syntax.
Testing with %I64d shows correct results in 3.4.5 and 4.
Same code copied to OSX (Intel), compiled with default gcc 4.0.1
gives the right result:
---
TEST NUMBER = [50]
---
Brgds,
Viktor
On 2008.09.25., at 20:58, Szakáts Viktor wrote:
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the f
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the folowing code:
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n", 50LL );
return 0;
}
Gives me:
TEST NUMBER = [705032704]
In MinGW 3.4.5 (official - t
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> After some experimenting it looks like -gc3 is the culprit.
I expected that it may be related to -gc3 switch and before
I wrote this message rebuild Harbour with -gc3 using Linux GCC
and cross MingGW. Everything works as expected.
> This c
On Thu, 25 Sep 2008, Przemyslaw Czerpak wrote:
> In my GCC final code looks for -O3 is:
> func:
> pushl %ebp
> movl%esp, %ebp
> subl$8, %esp
> movlhb_stack_ptr, %ecx
> movl4(%ecx), %eax
> add
Hi Przemek,
After some experimenting it looks like -gc3 is the culprit.
This can be easily seen even by using harbour.exe from the
official MinGW binary package.
You short sample program, compiled with -gc3 will produce
this line:
---
hb_xvmPushLongLong( HB_LL( 705032704 ) );
---
Brgds,
Viktor
On Thu, Sep 25, 2008 at 7:22 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> This is very serious problem.
> Just try:
> proc main()
> ? 50
> return
I don't know if it helps but I've just tried with current official mingw 3.4.5:
$ gcc -v
Reading specs from c:/mingw/bin/../li
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>>> tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990.
>>> Actually the new MinGW results are the right ones, but the
>>> expected results seem to be screwed up, showing 705032704 instead of
>>> 50. Quite strange. ]
>> Can y
On Thu, 25 Sep 2008, Przemyslaw Czerpak wrote:
Hi All,
> The cost of TLS access is strictly compiler/OS dependent. I've
> just make interesting experiment to compare the code of using
> stack pointer to dynamically allocated stack instead of statick
> stack address in ST programs.
> I made very s
Hi Przemek,
tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990.
Actually the new MinGW results are the right ones, but the
expected results seem to be screwed up, showing 705032704 instead of
50. Quite strange. ]
Can you send the exact hbtest output?
Pls find them attached
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>> [ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm
>> still getting the same error as above. Maybe I'm doing
>> something wrong, which could well may be given the zillions
>> of factors involved. ]
> I did something wrong. Too much comp
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>
> [ Update: After removing both from 1.0.1 builds, I got _just slightly_
> bigger binaries, and about identical performance. As a downside, now
> I'm getting 44 errors in hbtest, due to failing Round() and Int()
> tests: 914, 917-920, 923-92
Hi Przemek,
[ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm
still getting the same error as above. Maybe I'm doing
something wrong, which could well may be given the zillions
of factors involved. ]
I did something wrong. Too much compilers and compiled
environments on one computer...
Hi Przemek,
I've built mingw with -DHB_USE_TLS (the rest is default),
then I got 'undefined reference to '__emutls_get_address'
errors on linking. Such symbol doesn't BTW exist in MinGW
4.3.2 supplied libs.
AFAIR the work on TLS support for MinGW started at the begining of
summer so probably
On Wed, 24 Sep 2008, Szak�ts Viktor wrote:
Hi all,
> I've built mingw with -DHB_USE_TLS (the rest is default),
> then I got 'undefined reference to '__emutls_get_address'
> errors on linking. Such symbol doesn't BTW exist in MinGW
> 4.3.2 supplied libs.
AFAIR the work on TLS support for MinGW st
Hi all,
I've built mingw with -DHB_USE_TLS (the rest is default),
then I got 'undefined reference to '__emutls_get_address'
errors on linking. Such symbol doesn't BTW exist in MinGW
4.3.2 supplied libs.
Then I went with the fully default build, and it worked okay.
Final mingw speedtst results a
26 matches
Mail list logo
