search

libtom / tomsfastmath

TomsFastMath is a fast public domain, open source, large integer arithmetic library written in portable ISO C.
http://www.libtom.net
Other
213 stars 66 forks source link

how to build on macos x86_64 #5

Closed hellok closed 7 years ago

hellok commented 11 years ago

1. ifndef SIGCLD define SIGCLD SIGCHLD endif solved

2.src/mont/fp_montgomery_reduce.c:514:15: error: unknown register name '%cc' in asm INNERMUL8;

buggywhip commented 10 years ago

I too am encountering the same problem. (affects fp_montgomery_reduce.c, fp_mul_comba.c, and fp_sqr_comba.c)

The only reference I find to CC is WRT Motorola's 68K processors. Actually it is CCR (Condition Code Register) and some have since chosen to shorten it to just CC. Suspecting it is a "leftover"...

I simply removed the references to "%cc" found under the switch "X86_64" in each of the three affected files. I built the library including the provided program "test". Running test revealed no errors.

Not knowing whether this fix would be applicable to all processors I did not generate a patch. Perhaps someone with ARM, MIPS, etc experience can make that determination.

buggywhip commented 10 years ago

Correction to above post: I meant to say switch "TFM_X86_64", not "X86_64".

danfe commented 10 years ago

While gcc accepts %cc and %memory, the syntax is wrong, since % is only used for registers. Clang currently rejects these bogus constructs (and that's fine).

Similar fix was applied to NSS by Mozilla team before.

sjaeckel commented 10 years ago

I've applied the patches and tfm compiles now with gcc and clang

can someone verify that this also fixes the build problems on mac os?

buggywhip commented 10 years ago

On Jun 14, 2014, at 3:20 AM, Larry Bugbee bugbee@mac.com wrote:

For the record, I'm running a 2.53GHz Core2Duo, a P8700. http://www.cpu-world.com/CPUs/Core_2/Intel-Core%202%20Duo%20Mobile%20P8700%20AW80577SH0613MG%20%28BX80577P8700%29.html

I believe I am using correct flags. ...but am I?

I'm also assuming the 1st Montgomery KAT is correct. ...but is it? Do you know for sure? Perhaps tomorrow I write an independent program to verify.

fp_read_radix(&a, "234892374892374893489123428937892781237863278637826327367637836278362783627836783678363", 10); fp_read_radix(&b, "4447823492749823749234123489273987393983289319382762756425425425642727352327452374521", 10); fp_read_radix(&c, "2396271882990732698083317035605836523697277786556053771759862552557086442129695099100", 10); fp_montgomery_setup(&b, &dp); fp_montgomery_reduce(&a, &b, dp); if (fp_cmp(&a, &c)) { DISPLAY("mont failed\n"); return 0; } else { DISPLAY("mont passed\n"); }

My OSX build* of TFM and all tests appear satisfactory, including the two Montgomery tests in demo/test.c, except...

I'm unable to get the 3 Montgomery KATs in demo/stest.c to calculate the expected value under TFM. ...likewise under LTM. (I basically change fp to mp and link to the other lib.) Nor do the calculated Montgomery values, for both TFM and LTM, agree with each other. Something is very wrong! ???

Does demo/stest.c work for you? What processor and what flags?

Clues? Things I should check?

I'm now in the hunt for another lib with Montgomery to see if I can get anything to agree with anything else.

Larry

build* note: There are some warnings during the compile of demo/test.c similar to this... demo/test.c:253:50: warning: format specifies type 'unsigned long long' but the argument has type 'ulong64' (aka 'unsigned long') [-Wformat] printf("%5lu-bit: %9llu\n", t * DIGIT_BIT, t2);


                        %9lu
sjaeckel commented 10 years ago

Thanks for trying out @buggywhip I've seen the same issue with Montgomery and stest yesterday and also tried the same approach and did not succeed with LTM...

But now I tried the 32bit mode on 64bit CPU's with "gcc -m32" and stest succeeds...

I'm running on Linux Mint. Tried gcc 4.7.3 and 4.8.1

Steffen

buggywhip commented 10 years ago

On Jun 14, 2014, at 8:11 PM, Larry Bugbee bugbee@mac.com wrote:

I'm now in the hunt for another lib with Montgomery to see if I can get anything to agree with anything else.

Attached are two programs. The first is a short OpenSSL test program, mr-openssl.c, which looks at the three Montgomery reduction KATs found in stest.c. The second program is a slightly modified version of stest.c that 1) shows the calculated result when a test fails, and 2) doesn't stop so we can see the remaining test cases.

WRT the stest.c KATs, a 64-bit mr-openssl agrees with KAT cases 2 and 3 only. mr-openssl's different result for case 1 is 942974496560863503657226741422301598807235487941674147660989764036913926327577165648

With the exception of the 94297..648 number above, it appears TFM in 64-bit mode agrees with the OpenSSL results. I cannot say the same for 64-bit LTM.

In 64-bit mode, mr-openssl gave the following result.

miniServer:tomsfastmath-master bugs$ mr-openssl

Test case 1 a = 234892374892374893489123428937892781237863278637826327367637836278362783627836783678363 b = 4447823492749823749234123489273987393983289319382762756425425425642727352327452374521 r = 942974496560863503657226741422301598807235487941674147660989764036913926327577165648

Test case 2 a = 2348923748923748934891234456645654645645684576353428937892781237863278637826327367637836278362783627836783678363 b = 444782349274982374923412348927398739398328931938276275642542542564272735232745237452123424324324444121111119 r = 45642613844554582908652603086180267403823312390990082328515008314514368668691233331246183943400359349283420

Test case 3 a = 234823424242342923748923748934891234456645654645645684576353424972378234762378623891236834132352375235378462378489378927812378632786378263273676378362783627555555555539568389052478124618461834763837685723645827529034853490580134568947341278498542893481762349723907847892983627836783678363 b = 44478234927456563455982374923412348927398739398328931938276275642485623481638279025465891276312903262837562349056234783648712314678120389173890128905425242424239784256427 r = 33160865265453361650564031464519042126185632333462754084489985719613480783282357410514898819797738034600484519472656152351777186694609218202276509271061460265488348645081

miniServer:tomsfastmath-master bugs$

sjaeckel commented 10 years ago

wow, thanks!

but attached is ... nothing ... github_issues--

probably we should move this discussion to the ML... @buggywhip can you please send the mail to the ML?

sjaeckel commented 7 years ago

I just tested the build on Mac OS X 10.12.4 and it works fine from current develop.

Latest release spits some warnings and makefile.shared was broken.

I'm closing this, as it's resolved.