On Wednesday 04 June 2003 11:37, Bernard Mentink wrote: > Thanks David, will do as you suggest. > > In answer to your question, this module is part of the nesos FSM > operating system (available on the net). When I say it "doesn't work", > I mean that when a print format instuction is executed (which uses > functions from this module), the whole program locks up, or continually > reset's. ..... only with -02 optimization though. > I got the same situation with a _real_ hardware: when I print a line more than 32 bytes, CPU behaviour is tricky -- it resets a counter somehow and disables output of one line (port pin). When I reduce a number of bytes to be printed -- this is Ok.
When I start analyzing the problem, I found, that i forgot about that stack is not made of rubber -- it just overruns ram's bottom and cpu is unpredictable. I carefully analyzed all assembler files and fond no compilation errors. If I locate one I fix it immediatelly. Concerning FP benchmarking. All FP code is originally written by DEC and not optimized for small cpus. I just took that code (from newlib) and made it 'runnable'. If you want to improve it -- be my guest. ~d > I will start splitting stuff up and do it the hard way .... just > thought someone with gdb could spend 5mins compiling it and running it > through the debugger. > > Cheers, > Bernie > > On Wednesday, June 4, 2003, at 07:04 PM, David Dyck wrote: > > First, a question for the rest of the list. > > > > Does the msp430-gdb have support for the msp430 simulator? > > > > > > On Wed, 4 Jun 2003 at 16:17 +1200, Bernard Mentink > > > > <[email protected]>...: > >> Well like I said -- please read original post --- I don't have gdb to > >> locate the bug, I was hoping someone else > >> could run the code through gdb ..... > > > > There are 2 non-ifdef'ed functions in the file you posted. > > > > Could you split the .c file into 2 parts, one for each function, > > and compile on function with -O and the other with -O2, and visa versa? > > That would narrow the problem down a little. > > > > You said "it doesn't work", but perhaps you could describe > > the input to the function that is failing, the expected results, > > and what you got. (Are your test cases in the #ifdef TEST code, > > that is not currently compiled? Which cases fail?) > > > > There are 2 switch statements, perhaps based on the failing input, > > you could remove the other cases, again, reducing the problem. > > > > David > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The > > best > > thread debugger on the planet. Designed with thread debugging features > > you've never dreamed of, try TotalView 6 free at www.etnus.com. > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- /******************************************************************** ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314 ********************************************************************/
