Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => TI-Nspire => Topic started by: sammyMaX on August 13, 2011, 04:19:36 pm

Title: BigNumNum Cruncher
Post by: sammyMaX on August 13, 2011, 04:19:36 pm
BigNumNum Cruncher is a bignum program for the Nspire, written in C. It should be able to handle numbers as big as the Nspire's RAM allows it to be, with one digit per byte. (This may not mean output being up to (number of available bytes of RAM) digits long, since in the instance 2^1000000, it would need to store 2^999999 to get to 2^1000000) I have finished the addition and multiplication functions, and have the basic GUI going, but a lot of work has to be done (Powers in beta testing for now) I have no school on 9/29/11, so hopefully some major work can be done.

BigNumNum Cruncher originally started in Lua but since then, I have moved over to C, since Lua was far too slow for this program. Numbers are stored in my program as arrays of ints, with only 4 digits able to be used in each int because of overflow. (Perhaps there is a way to fully utilize the RAM and double capacity?)

Spoiler For Changelog:
Version 0.01 Lua with GUI done
Version 0.02 Lua with addition
Version 0.03 Lua with subtraction
Version 0.04 Lua with multiplication and powers
Version 0.05 Lua with bug fixes

Version 0.10 C with GUI and addition
Version 0.11 C with less bugs
Version 0.12 C with multiplication
Version 0.13 C with powers and results less than 37 digits
Version 0.14 C with major speed up in addition and subtraction algorithms
Version 0.15 C major release memory allocation bug fixed
Title: Re: [Lua] BigNumNum Cruncher
Post by: sammyMaX on August 14, 2011, 11:05:34 am
Update: I have decided to move over and start the program in C with Ndless 2.0. It will be much faster, and when Ndless 3.0 comes out, only a few minor changes will have to be made. Expect an alpha in three to four days.
Title: Re: [Lua] BigNumNum Cruncher
Post by: sammyMaX on August 21, 2011, 04:47:55 pm
Here is the UI in C (so far not functional):
On a side note, I am having a lot of trouble implementing the GMP-style limbs and branches, (Ndless isn't letting me do divison or mods) so I will revert back to my old system of numbers.
Title: Re: [Lua] BigNumNum Cruncher
Post by: Spyro543 on August 21, 2011, 08:53:46 pm
Awesome looking! (Why would you even need to calculate numbers this big anyways? :P)
Title: Re: [Lua] BigNumNum Cruncher
Post by: fb39ca4 on August 21, 2011, 09:35:34 pm
Are you having trouble with 64-bit (or possibly 32-bit) integer division? Is there a compiler error when you do so?
Title: Re: [Lua] BigNumNum Cruncher
Post by: sammyMaX on August 21, 2011, 10:03:41 pm
Spyro - Thanks! Most people won't need it, but it could be cool to show to your friends, and for those in math competitions (like Mathcounts) it could be a life saver.

Toxic kitten - yes, I am getting an error when doing mod (%) and division. I get compiler errors like "undefined reference to '__aeabi_idivmod'" or "undefined reference to '__aeabi_uidiv'". It would really help if you could explain this to me.
Title: Re: [Lua] BigNumNum Cruncher
Post by: fb39ca4 on August 22, 2011, 01:00:04 am
You are getting errors from newlib then. Make sure you have the latest version of GCC.
Title: Re: [Lua] BigNumNum Cruncher
Post by: Lionel Debroux on August 22, 2011, 01:36:32 am
Quote
"undefined reference to '__aeabi_idivmod'" or "undefined reference to '__aeabi_uidiv'". It would really help if you could explain this to me.
Don't use the -nostdlib compiler option :)
Title: Re: [Lua] BigNumNum Cruncher
Post by: Spyro543 on August 22, 2011, 07:14:31 am
Spyro - Thanks! Most people won't need it, but it could be cool to show to your friends
Most of my friends don't even know what a graphing calculator is. :P
Title: Re: [Lua] BigNumNum Cruncher
Post by: sammyMaX on August 22, 2011, 08:43:06 am
The -nostdlib option was the problem. (from me just modifying the makefile of the Hello sample and never catching on to that) Thanks guys!

Lol Spyro, in my school graphing calculators are required for 9th grade and above math. TI must make a lot of money off that...
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on August 22, 2011, 10:35:39 am
Some random tidbits about Lua vs. C (for Nspire programming)
1. C is much better for input, because it keys being pressed instead of the character a button corresponds to (which is sometimes a weird, non-standard character)
2. C is MUCH faster
3. Lua supports color and developing for it is much easier
4. For my program, where the input is a variable length, C is HORRIBLY hard to code. In Lua a string can be any length; getting C to create a string that can be a variable size (but stays the same length after declaration) requires malloc(), and when the string length changes each time you type... UGH!!!
Title: Re: [Ndless] BigNumNum Cruncher
Post by: calc84maniac on August 22, 2011, 12:25:48 pm
getting C to create a string that can be a variable size (but stays the same length after declaration) requires malloc(), and when the string length changes each time you type... UGH!!!
Try using realloc(), that will resize a buffer without modifying its contents (and may return a new pointer if the buffer couldn't be resized in-place). Of course, you may not want to reallocate for every character typed, so you could probably increase/decrease the size by, for example, 32 bytes at a time.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on August 25, 2011, 08:17:19 pm
True... I really don't know what I was thinking when I wrote that post ??? because I had thought of realloc(), but for some reason it still seemed like a pain in the butt to write.

An update: I have 3-4 weeks to finish (at least get the most important power, factorial and multiplication functions done) before school starts. I plan on writing division and nth root approximation, but I haven't really learned that yet, so it may be far later in development when that gets implemented.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: fb39ca4 on August 26, 2011, 12:48:09 am
I just make my string buffers long enough for whatever may occur. I never thought of using realloc :P
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on August 26, 2011, 10:51:35 am
Yeah, that works, but it isn't very elegant (seriously, using up like half a KB of RAM is not really a worry, it just doesn't seem pretty)
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on August 31, 2011, 11:42:36 am
Many of the math functions are done (actually quite easy to program, as long as you're not SUPER optimizing) and I am around 60% done with input processing (turning string into the data type my functions take in) and haven't done output processing yet (data type returned from functions into string) Once I'm done with input processing, a beta should come out soon, (output processing isn't as bad) but programming input processing is a PITA. I can see why Cabamap used RPN, it is a lot easier to work with.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 02, 2011, 05:11:57 pm
OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

LOL  8)

Anyways, it can now (usually) add. It is still very unstable though, and it is very hard to type in input. I have a solution in mind, and if it works I will post it. (From what I've experienced, others have the same issue)
Title: Re: [Ndless] BigNumNum Cruncher
Post by: Hayleia on September 03, 2011, 02:21:58 am
Great work !!!
/me is sad to not have an Nspire :'(
[offtopic] You also can go to Graphmastur's Power of two posters only (http://ourl.ca/10892/206853) topic, since you have 64 posts [/offtopic]
Title: Re: [Ndless] BigNumNum Cruncher
Post by: Chockosta on September 03, 2011, 04:29:28 am
Well done !

This is a nice program... Keep up the good work !
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 03, 2011, 10:23:11 am
Thanks!
@Hayleia: before posting this (when I had 64 posts) I still got "An Error Has Occurred!" page. :(
Title: Re: [Ndless] BigNumNum Cruncher
Post by: Hayleia on September 03, 2011, 10:31:05 am
I still got "An Error Has Occurred!" page. :(
??? Maybe it is because it is in Spam, you may need 100 posts, I don't know.
You'll go when you have 128 posts :D
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 03, 2011, 10:38:57 am
I can't wait :)
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 03, 2011, 04:59:23 pm
I'm having a problem creating (certain) arrays. I use calloc(x, sizeof(int)). No matter what x is, the pointer returned always points to an array of one integer. More info (and a screenshot of the problem) here, at the bottom of the page: http://ourl.ca/119180
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 04, 2011, 10:57:00 am
I got it fixed :) Development continues... (school starts soon, though, so progress will slow down a lot)
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 04, 2011, 03:06:59 pm
Almost done with addition! Some more screenshots.
Bugs/Annoyances:
✓  A pain to type in input - very unresponsive keys - solved enough!
✓ Input 1 has to be longer than input2 - solved!

After these are fixed, it will be time to go to the focus of the program, multiplication! Of course, this also includes functions composed of multiplication - powers, nCr, nPr, and factorial. The two biggest problems (I foresee) are memory allocation (especially for things like factorial) and more annoyances with processing input.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 11, 2011, 10:40:21 am
School has started, but the work hasn't piled up yet :) I finished multiplication, and it's bug free, as far as I can tell. I'm quite proud of my algorithm - it's slightly better than how a person would multiply numbers on paper, in that their is no buffer made for the product of the top multiplicand and one of the digits in the bottom. This should prove very useful and increase capacity by a lot (maybe double the length possible) for operations like 2^5000. My program stores numbers with one digit per byte, so numbers with millions of digits should be computable, with speed permitting.

Time to move on to the heart of the program - large number functions such as factorials and powers! After that, I will write the all-important large number interface so one could actually do useful things with the number, like see the nth digit of it (when there are so many digits the screen can't fit them all).
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 25, 2011, 09:56:34 am
Hi guys it's been a while :) I have some time this weekend so I'm hoping to get at least some work done on this program.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on September 30, 2011, 09:14:15 pm
Now powers are done, but the result can only be less than 37 digits long (width of screen) I haven't bothered to program anything for output longer than that, since multiplication and addition would never get numbers that big. Expect an update (hopefully) tomorrow.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on January 15, 2012, 07:28:50 pm
Help?
Title: Re: [Ndless] BigNumNum Cruncher
Post by: Hayleia on January 18, 2012, 12:18:50 pm
Is the problem that it can't display the whole number and puts "..." instead ?
I don't know anything about your program but if it treats the output as a string, it can check the length and split it if needed to display parts of it (I don't know if that is possible or if that can work :P).
Title: Re: [Ndless] BigNumNum Cruncher
Post by: lkj on January 18, 2012, 02:26:14 pm
The problem is that a power of two can't be odd like in the second picture.
Have you some code?
Title: Re: [Ndless] BigNumNum Cruncher
Post by: Hayleia on January 18, 2012, 02:43:17 pm
ah, yes, a power of two that terminates by a 9 O.o
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on January 18, 2012, 06:36:28 pm
I actually programmed it to use the "..." when the entire output is too large to fit.
The first picture (showing 2155) is correct, while the second one, 2210, is not. I noticed that it always outputs a number with a lot of 2809's and 2810's when it's not correct.

There is a part of my program that might be screwing up. One of the parameters my power function takes in is an array of ints that will be the output.
Code: [Select]
int numPow(int in1[], int in2[], int output[], int in1len, int in2len)For that parameter (called output[]), I pass it the pointer to an array, and the array has only one int in it.
Code: [Select]
int *ans = malloc(4); // One int
int ansLen = numPow(in1, in2, ans, numInts1, numInts2);
The power function keeps calling my multiplication function, and resizes the array whenever it needs to. (Now that I think about it, this might not be so smart)

I'm thinking that if the array grows too large, and it has to move to a different address, my pointer (named ans) won't update to the new address, so it will point to the old one, which is now full of garbage.

Also, (Not really related) If you have:
Code: [Select]
int a;
int b = 2000000000; // Still within range
int c = 2000000000; // Still within range
a  = (b * c) % 10000000000; // Last 10 digits of the product
Does that work, or will it cause overflow? I am wondering because right now, I am storing numbers as arrays of ints with 4 digits in each int, which is quite inefficient.
Title: Re: [Ndless] BigNumNum Cruncher
Post by: sammyMaX on January 18, 2012, 08:49:23 pm
YESSS!!!

It was what I thought - the array grew too large and the pointer ended up pointing to some random section of RAM.

Behold - the largest numbers ever computed on the Nspire!
Note: it took around 3-4 seconds to do 29001
Title: Re: [Ndless] BigNumNum Cruncher
Post by: Hayleia on January 20, 2012, 03:45:55 pm
Great job ! :D
This will be very useful for arithmetics. You know when they ask you "what is the relainder when you divide 29001 by 193 ?" and you have to find a power n of 2 with 2n==1[193] because they think the calc is slow, with your engine, you just write the calculus and it is done :P
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on January 20, 2012, 05:05:13 pm
Thanks! :)

I do a lot of math contests, and although the Nspire has helped a lot in them (at least the ones where calculators are allowed) I always dreamed of something more powerful, something that could answer a question like, "find the sum of the digits of 800!"
Title: Re: BigNumNum Cruncher
Post by: lkj on January 20, 2012, 07:17:14 pm
Also, (Not really related) If you have:
Code: [Select]
int a;
int b = 2000000000; // Still within range
int c = 2000000000; // Still within range
a  = (b * c) % 10000000000; // Last 10 digits of the product
Does that work, or will it cause overflow? I am wondering because right now, I am storing numbers as arrays of ints with 4 digits in each int, which is quite inefficient.

Yes, it will overflow, my compiler gives a warning.

Why do you only store 4 digits in one int, and not more?
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on January 21, 2012, 09:13:40 am
If I store x digits per int, I only want the last x digits of a product (or sum or difference) and send the rest as a carry. That means all the numbers I get as results will be in the range of an int, but during the intermediate steps, some numbers will come out that don't fit in the integer range. For example, if I store 10 digits per int, and multiply them, the carry will be within range, and the last 10 digits will also be in range, but the product of the two numbers itself won't be. Storing 4 digits per int is the max that keeps all multiplications within range of an int.
Title: Re: BigNumNum Cruncher
Post by: steelfirez on January 23, 2012, 07:47:21 pm
That's pretty cool. I participate in math contests a lot, and this would be really helpful. I'll type up some stuff later.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on January 28, 2012, 06:40:21 pm
Version 0.16a: multiplication is around 20% faster, and a bug was fixed that allowed exponents to only be up to four digits in length.

More importantly, the exponentiation algorithm has been improved significantly - it now uses exponentiation by squaring (http://en.wikipedia.org/wiki/Exponentiation_by_squaring) instead of the naive method. The calculation times grow much slower now, and the difference in speed grows larger as the exponent grows. Here's a chart comparing speeds of 0.15a and 0.16a doing powers of two:
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on February 20, 2012, 02:27:27 pm
I haven't had much time to work on my project, but Winter Break = time to code :)
My checklist of things to do:
1. Allow large numbers to be viewed easily
2. Program:
   a. Sum of digits
   b. Trailing zero counter
   c. Factorial
   d. nCr
   e. Division
3. Make a menu system

By the way, did anyone take the AMC 10/12? How did you do?
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on February 21, 2012, 05:03:36 pm
Version 0.17a now with sum of digits completed. Unfortunately, this function won't be very useful until I program it so that the other input lines can be used (right now you can only type in line A) Also, I changed it so each input line is identified by number instead of letter.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on February 26, 2012, 09:46:22 am
I made a custom radical sign character :)
It currently replaces the "1" character, so that's why the version number is so funny. :P

Meanwhile, I removed the memory usage indicator because it would be hard to program and useless, and I'm also working on porting GMP so I don't have to use my silly slow math algorithms. If that turns out successful, I will stop using my own math functions and just focus on programming a GUI.
Title: Re: BigNumNum Cruncher
Post by: ruler501 on February 26, 2012, 01:03:53 pm
Could you post the source for this? I'd like to see if I could help and/or just look at it

Great job btw
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on February 28, 2012, 08:01:16 pm
Here's the source and stuff. I work with Ndless 1.7 because it is supported by Ncubate, which I use for debugging, so sorry if it's not compatible with what you use.
Title: Re: BigNumNum Cruncher
Post by: ExtendeD on February 29, 2012, 02:03:07 am
Sorry for not maintaining Ncubate, there seems to be unfortunately too few users to be worth the effort...
Title: Re: BigNumNum Cruncher
Post by: Lionel Debroux on February 29, 2012, 07:32:24 am
Among others, I use Ncubate ;)

For my information, how large is the diff between nspire_emu 0.32b and Ncubate 0.32b ? I don't have their sources handy to make the diff by myself.
Title: Re: BigNumNum Cruncher
Post by: Jonius7 on February 29, 2012, 07:39:01 am
Hmm I have both of those. And not really much difference, except Ncubate has the ability to save state, so it doesn't have to restart up the OS everytime.
And We are going off topic here, but good to you ExtendeD for informing us.
This Num Cruncher does look quite interesting.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on February 29, 2012, 04:35:01 pm
Ncubate has been very useful for my debugging purposes, and the calc starts up instantly with it, a nice bonus :)
I don't really mind if you don't update it, ExtendeD, because updating a program to work on a new version of Ndless is quite trivial.

By the way, can any of you guys help me port GMP? I'm getting some errors where it can't find the functions: http://ourl.ca/15308/287327 (http://ourl.ca/15308/287327)
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 11:08:22 am
I looked at your code a bit and had some questions:
Do you really want to #include <string.h> and not #include "string.h"? Because like this you never include your own string.h.
And I couldn't find where you free() in1 and in2.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 12:08:26 pm
Yeah that was a pretty fail include I guess... it's outdated as well, now that os.h has all the string functions one would need.
As for in1 and in2, that was pretty fail as well, because if you press enter multiple times, the old instances of in1 and in2 would become inaccessible and it would be a memory leak. They really should be freed as soon as the operation is done. Ans also has the same problem - pressing enter will make a new instance of it each time. Ans should really be declared in the beginning of my program and freed and reassigned whenever the answer of a line changes.

The program, when finished, will be able to have different inputs on each line, and so things like output1, inputLen, and ans will have to turn into arrays, one of them for each line. I haven't done that yet and I haven't worked on the program recently as I am more interested in porting over GMP and make a GUI for it.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 01:46:37 pm
Unfortunately I can't help you port GMP because I don't know much about libraries.
And GMP even doesn't compile correctly for me, I'm getting some errors that it "cannot determine how to define a 32-bit word" :(
Title: Re: BigNumNum Cruncher
Post by: Lionel Debroux on March 01, 2012, 02:24:03 pm
These problems look weird, be they the undefined differences or the compiler being unable to determine how to define a 32-bit word :(
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 02:57:13 pm
All the errors I get:

Code: [Select]
mv: cannot stat `gmp-5.0.4': No such file or directory
mkdir: cannot create directory `build': File exists
mkdir: cannot create directory `prefix': File exists
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
../src/configure: line 27268: /c/Program: No such file or directory
configure: WARNING: +----------------------------------------------------------
configure: WARNING: | Cannot determine global symbol prefix.
configure: WARNING: | /c/Program Files (x86)/yagarto/bin/arm-none-eabi-nm output doesn't contain a global data symbol.
configure: WARNING: | Will proceed with no underscore.
configure: WARNING: | If this is wrong then you'll get link errors referring
configure: WARNING: | to ___gmpn_add_n (note three underscores).
configure: WARNING: | In this case do a fresh build with an override,
configure: WARNING: |     ./configure gmp_cv_asm_underscore=yes
configure: WARNING: +----------------------------------------------------------
configure: WARNING: "/c/Program Files (x86)/yagarto/bin/arm-none-eabi-nm" failure
configure: WARNING: cannot determine local label, using default L
../src/configure: line 27607: /c/Program: No such file or directory
../src/configure: line 27607: /c/Program: No such file or directory
configure: error: cannot determine how to define a 32-bit word

Edit: I'm more or less using the script you posted, but without the download commands:
Code: [Select]
#!/bin/sh
# This creates a "gmp" subdirectory whereever you launch the script, and compiles and installs in subdirectories thereof.
WORKING_DIR=`pwd`
mv gmp-5.0.4 src
mkdir build
mkdir prefix
cd build
../src/configure --host=arm-none-eabi --prefix="$WORKING_DIR/prefix" --enable-shared=no --enable-assert || exit 1
make && make install
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 03:01:42 pm
I think a lot of the errors come from not having the proper folders and not having the privileges to create the folder.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 03:17:29 pm
/c/Program Files (x86)/yagarto/bin/arm-none-eabi-nm is a correct path, but /c/program obviously isn't. I'm asking myself why it searches anything in that folder when no windows pc has such a path ??? And why it worked for you but not for me ???
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 03:18:11 pm
I'm in Linux :)
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 03:25:54 pm
Hm, but it seems that it should also work on windows. At least the script runs in msys.
And the first three errors are only there because I had to rerun the script to copy the logs, they didn't change anything about the result.

Edit: Could it be that it uses yagarto and another gcc? Because gcc --version outputs 4.5.2 and yagarto says it uses gcc 4.6.2, so these could be incompatible?
Title: Re: BigNumNum Cruncher
Post by: Lionel Debroux on March 01, 2012, 03:30:21 pm
It's not a problem of GCC version number :)

Many programs and scripts tend to break when they're run from a path which contains spaces. Install MSYS in C:\MSYS, and it ought to work much better ;)
My script should be able to cope with it, because I put quotes (--prefix="$WORKING_DIR/prefix") for that reason, but the configure script probably doesn't.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 03:31:27 pm
Oh yeah! C:\Program is probably just C:\Program Files, but the space screws everything up.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 03:38:06 pm
I had it in C:\MinGW\msys\1.0, so no space. But I'm installing it again anyways. Should I use 1.0.11 or newer? And should I update gcc to gcc 4.6.3?
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 03:39:02 pm
Is it perhaps YAGARTO's fault?
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 03:44:20 pm
I reinstalled msys to c:/msys and get the same error. And the line which gives the error in the configure script is much too difficult for me to just patch it. Or even to figure out what it does.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 03:49:02 pm
Perhaps it has something to do with YAGARTO, because in the thing you posted, the error on line 9 has to do with it.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 03:54:08 pm
Perhaps. Now that I'm looking at their website again I see that it says you shouldn't install yagarto to a path which contains spaces, but it automatically installed there and I never had any problems before. But I'll reinstall it.

Now I have installed it to c:\yagarto and still the same errors.
I haven't more time to look at this today because it's 10pm and I have a test in French and a presentation in English tomorrow.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 04:23:38 pm
Actually I was wrong, the errors changed. Now they are

Code: [Select]
c:\yagarto\bin\arm-none-eabi-nm.exe: conftest.o: File format not recognized
configure: WARNING: +----------------------------------------------------------
configure: WARNING: | Cannot determine global symbol prefix.
configure: WARNING: | /c/yagarto/bin/arm-none-eabi-nm output doesn't contain a global data symbol.
configure: WARNING: | Will proceed with no underscore.
configure: WARNING: | If this is wrong then you'll get link errors referring
configure: WARNING: | to ___gmpn_add_n (note three underscores).
configure: WARNING: | In this case do a fresh build with an override,
configure: WARNING: |     ./configure gmp_cv_asm_underscore=yes
configure: WARNING: +----------------------------------------------------------
configure: WARNING: "/c/yagarto/bin/arm-none-eabi-nm" failure
configure: WARNING: cannot determine local label, using default L
c:\yagarto\bin\arm-none-eabi-nm.exe: conftest.o: File format not recognized
c:\yagarto\bin\arm-none-eabi-nm.exe: conftest.o: File format not recognized
configure: error: cannot determine how to define a 32-bit word

Is it normal that it contains windows-style paths and linux-style paths?
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 04:49:14 pm
If you didn't configure it for the Nspire, make sure to do that. Instead of just ./configure, do ./configure --host=arm-none-eabi
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 05:00:46 pm
The script I used has this in it.
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 05:02:50 pm
I don't know then. Perhaps someone with more knowledge can help you.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 01, 2012, 05:08:05 pm
And you also have yagarto with binutils version 2.21 and gcc 4.6.2?
Title: Re: BigNumNum Cruncher
Post by: sammyMaX on March 01, 2012, 05:16:18 pm
I do, but I never installed GMP with it. I have GMP installed on Ubuntu 11.10, where you don't need such things.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 03, 2012, 01:21:22 pm
Does anyone know why configure calls mingw's gcc and not yagarto's gcc? What should I change?

Now I know why, somehow it doesn't find yagarto's gcc, even though its path is in my PATH environment variable.
Title: Re: BigNumNum Cruncher
Post by: lkj on March 03, 2012, 02:59:23 pm
It does find the correct gcc, but the problem seems to be an "undefined reference to '_exit'" in newlib :(

The important part of config.log:

Code: [Select]
configure:5440: checking compiler arm-none-eabi-gcc -O2 -pedantic -fomit-frame-pointer
Test compile:
configure:5454: arm-none-eabi-gcc -O2 -pedantic -fomit-frame-pointer  conftest.c >&5
c:/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-exit.o): In function `exit':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\stdlib/../../../../../newlib-1.19.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit'
collect2: ld returned 1 exit status
configure:5457: $? = 1
failed program was:

int main () { return 0; }
Title: Re: BigNumNum Cruncher
Post by: lkj on March 04, 2012, 02:05:34 pm
I figured out that the above error is the only real one, the other error about the 32 bit words was with the x86-gcc to which it fell back after arm-none-eabi-gcc had given an error.