Miscalleneous bugs in the 32bit compiler

For other topics related to the FreeBASIC project or its community.
stephanbrunker
Posts: 62
Joined: Nov 02, 2013 14:57

Re: Miscalleneous bugs in the 32bit compiler

Postby stephanbrunker » Dec 20, 2013 11:58

@fxm:
I'm from Germany, and in the german Version of the documentation SHARED the part regarding the strings is missing ...

@MichaelW and dodicat:
That's why I'd prefer rol and ror included in Freebasic. My ASM was likely the only one I could find with google at all. So, should I compile with -gas and include that code in my "patch" file, because it's the fastest way? I'm a litte new on all that stuff and I used only the standard options. Or have i to compile with different modules if I'm programming for Windows GUI?

But which should I take - thank you for all the variants, btw ...!

Code: Select all

function rol ( x as uinteger, y as uinteger ) as uinteger
    asm
        mov eax, [esp+4]
        mov ecx, [esp+8]
        rol eax, cl
        ret 8
    end asm
end function

function ror ( x as uinteger, y as uinteger ) as uinteger
    asm
        mov eax, [esp+4]
        mov ecx, [esp+8]
        ror eax, cl
        ret 8
    end asm
end function

Function roL2(N As Uinteger,S As Integer) As Uinteger
    Return N Shl S Or N Shr  (Sizeof(N)*8-S)
End Function

Function roR2(N As Uinteger,S As Integer) As Uinteger
    Return N Shr S Or N Shl (Sizeof(N)*8-S)
End Function


I really liked Richards bigint, because It was the easiest to understand and use by far. I couldn't find any documentation for the bigint library at all, and the "largeint.bas" is complicated to use (fixed allocated spaces for the bigint, special functions ..), Richards idea was great, just dim x as bigint and ready. But the problem was that Richards version was lightyears slower than the largeint and was not fully overloaded and the constructors and casts were imcomplete. So i took the time and rewrote a good deal of his code, especially the division and comparation (completely new and multiple times faster now) and improved the other operations to gain a few percent of speed. If you're searching for a 1024-bit Sophie-Germain prime with a lot of 1024 bit modular exponentiations (multiply,square and divide), even a litte bit multiplies. And if the processors are fast enough to do it really fast, you've to switch to even larger numbers to guarantee the safety of the discrete logarithm.

And of course, the bigints are stored in binary strings (two's complement) and if you search your errors, you've to convert everything to hex to be able to print and check it. And because of the signed nature, there're actually two versions of the conversion to hex: a signed one which has leading zeros if the highest bit is set, but the number is positive, and a unsigned one which trims these leading zeroes to get a specific length. If I understood it correctly, on a 64bit platform integer is 64bit and not 32, and this would completely mash up my blocks - so I tended to ulong which is fixed to 32 bits, but not supported in hex(a,n). Or would it be better to change the types to uinteger<32> ? (but this is also not supported in hex(a,n) ).
fxm
Posts: 9698
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Miscalleneous bugs in the 32bit compiler

Postby fxm » Dec 20, 2013 12:32

stephanbrunker wrote:@fxm:
I'm from Germany, and in the german Version of the documentation SHARED the part regarding the strings is missing ...

I updated the official documentation in June 2013 about that note.
You can visualize the updates with "Page History" command down each keyword page.
Page History for SHARED:
Most recent edit on 2012-06-13 15:26:56 by FxMwikki [shared variable of var-len string type never can be initialized, even with a constant string]

You should always prefer to work with FBWiki which is updated very often.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Re: Miscalleneous bugs in the 32bit compiler

Postby MichaelW » Dec 20, 2013 13:20

stephanbrunker wrote:

Code: Select all

function rol ( x as uinteger, y as uinteger ) as uinteger
    asm
        mov eax, [esp+4]
        mov ecx, [esp+8]
        rol eax, cl
        ret 8
    end asm
end function


Without the “naked” keyword that coding will not work, because the compiler will include the prologue and epilog code, and code to preserve EBX, EDI, and ESI, and the result will be that the displacements on the [esp+] operands will be off (by something like 20 bytes).

http://www.freebasic.net/wiki/wikka.php ... KeyPgNaked
gothon
Posts: 224
Joined: Apr 11, 2011 22:22

Re: Miscalleneous bugs in the 32bit compiler

Postby gothon » Dec 20, 2013 15:56

stephanbrunker wrote:@MichaelW and dodicat:
That's why I'd prefer rol and ror included in Freebasic. My ASM was likely the only one I could find with google at all. So, should I compile with -gas and include that code in my "patch" file, because it's the fastest way? I'm a litte new on all that stuff and I used only the standard options. Or have i to compile with different modules if I'm programming for Windows GUI?

But which should I take - thank you for all the variants, btw ...!


I recommend the strategy suggested in this post: http://www.freebasic.net/forum/viewtopic.php?f=17&t=22063#p193594

Since that method uses a macro and optimization, it introduces no function call overhead, requires no manual writing of assembly code and still produces fast single rotation instructions (assuming it worked).

stephanbrunker wrote:If I understood it correctly, on a 64bit platform integer is 64bit and not 32, and this would completely mash up my blocks - so I tended to ulong which is fixed to 32 bits, but not supported in hex(a,n).


I believe this is the plan, although 64 bit compiling is not yet officially supported though I do believe the gcc back-end is close to being able to compile to 64 bit code.
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: Miscalleneous bugs in the 32bit compiler

Postby MOD » Dec 20, 2013 16:32

stephanbrunker wrote:in the german Version of the documentation SHARED the part regarding the strings is missing

Fixed :)

fxm wrote:You should always prefer to work with FBWiki which is updated very often.

The german FreeBASIC Referenz is really up to date and in some points contains even more informations (e. g. about new features, that are only part of current git builds) than the FBWiki. But it's always a good idea to check both if possible.

PS: If something is missing in the german reference, just send me a PM, post on the german forum or come to the german oder international IRC channel and tell me or someone of our team and we will add it. :)
fxm
Posts: 9698
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Miscalleneous bugs in the 32bit compiler

Postby fxm » Dec 20, 2013 17:22

MOD wrote:The german FreeBASIC Referenz is really up to date and in some points contains even more informations (e. g. about new features, that are only part of current git builds) than the FBWiki.

Interesting, but it's bad for me in German!
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: Miscalleneous bugs in the 32bit compiler

Postby MOD » Dec 20, 2013 17:46

Yes, for you, but great for german users, especially if they have low english skills.^^
stephanbrunker
Posts: 62
Joined: Nov 02, 2013 14:57

Re: Miscalleneous bugs in the 32bit compiler

Postby stephanbrunker » Dec 20, 2013 21:10

Thank you folks!

I tested three versions:

my variant with no compiler options needed 11,4 seconds for 1 million blocks of salsa20 in my implementation.

asm with -gen gas needed 6,3 seconds

and #define with -gen gcc 6,2 seconds.
fxm
Posts: 9698
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Miscalleneous bugs in the 32bit compiler

Postby fxm » Dec 21, 2013 10:07

MOD wrote:The german FreeBASIC Referenz is really up to date and in some points contains even more informations (e. g. about new features, that are only part of current git builds) than the FBWiki.

Admin

Would not it be interesting (like the German documentation) of maintaining the FBWiki documentation up to date on the current fbc version (with the new features/behaviors well identified as being for the future official release) rather than waiting until the last moment to update the documentation just before the new official version released (and of course forget some things)?
I can do some updates regarding my skills.
fxm
Posts: 9698
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Miscalleneous bugs in the 32bit compiler

Postby fxm » Jan 05, 2014 10:55

fxm wrote:
MOD wrote:The german FreeBASIC Referenz is really up to date and in some points contains even more informations (e. g. about new features, that are only part of current git builds) than the FBWiki.

Admin

Would not it be interesting (like the German documentation) of maintaining the FBWiki documentation up to date on the current fbc version (with the new features/behaviors well identified as being for the future official release) rather than waiting until the last moment to update the documentation just before the new official version released (and of course forget some things)?
I can do some updates regarding my skills.

Given the lack of enthusiasm for my above proposal, I drop this one!
(for my part, it does not change much because I am aware of these new features/behaviors)
MOD
Posts: 555
Joined: Jun 11, 2009 20:15

Re: Miscalleneous bugs in the 32bit compiler

Postby MOD » Jan 05, 2014 12:53

Sometimes, we don't add everything, because it's too much of a change just for a future feature/change. Then we do this:

First, we copy the wiki code, as is (this means with all the wiki-specific tags etc.), to a new text file.
There we do all the changes and get them reviewed by other members.
If everything is alright, the text will be stored until the new version comes out.
Then, we just have to replace the old wiki code with the new one.

It's very simple and fast. You could do the same in such cases.
fxm
Posts: 9698
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Miscalleneous bugs in the 32bit compiler

Postby fxm » Jan 05, 2014 14:24

I think we should let the most up-to-date version of the documentation (matching the official fbc version + the current fbc version) accessible (for viewing or modifying) to all (for those working with official fbc version, and also those working with current fbc version).
I think managing two parallel versions is complicated for the postponement of the updates.
It is why I proposed to highlight the new features / behaviors with always the same tag referring (for example "fbc version 0.91.0").
So, just before the new official version release, it is easy to search each tag referring to the new version in order to adapt the text form only.

I mainly asked admin his opinion.
AnotherLife
Posts: 94
Joined: Feb 07, 2011 22:48

Re: Miscalleneous bugs in the 32bit compiler

Postby AnotherLife » Jan 05, 2014 15:44

stephanbrunker wrote:Thank you folks!

I tested three versions:

my variant with no compiler options needed 11,4 seconds for 1 million blocks of salsa20 in my implementation.

asm with -gen gas needed 6,3 seconds

and #define with -gen gcc 6,2 seconds.

What about with "-gen gcc -O 2" ?

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 6 guests