> David Brown wrote:
(It wasn't me that wrote this, it was the O/P - it's easy to get the
atribution mixed up, but I'd hate anyone to think I wrote the C "code" below
:-) I would, however, have written it as a dedicated function rather than
using the library code - I have a bad habit of doing that even when there is
no call for it on the grounds of size or space.)
>
> >>Horse and saddle to that guy who find what is wrong in below code:
> >>unsigned int oct2int(const char* oct){
>
> i know it's fun implementing the own algorithms, but i would take that
> one from the c library, this time ;-)
>
> #include <stdlib.h>
>
> long n;
> n = strtol("123", NULL, 8);
>
> that one can parse numbers of any base (0 == autodetect)
>
> >>unsigned int ret = 0;
> >>int i,j=0,k,length = strlen(oct);
> >>
> >> for(i=length-1;i >= 0;i--){
> >>if((k=(oct[i]-'0')) > 0) ret += 1<<(3*j) * k;//8 = 2^3
> >>j++;
> >> }
> >>return ret;
> >>}
> >
> >
> >
> > Did you learn to program at http://www.de.ioccc.org/main.html ?
>
> yep that site is fun :-)
>
> > What's
> > wrong with the code is that is is illegable - in my book, that makes the
> > code incorrect regardless of what happens when you try to compile and
run
> > it. It's also horribly inefficient (you are scanning the string twice,
> > using an unnecessary multiply, and using an unnecessary variable
shift) -
> > that's just not how you write code for embedded systems. I'd post an
> > example implementation, but Bill beat me to it.
> >
> > And if you want to post generated assembly (something that is often
useful
> > to aid debugging), avoid flags that do loop unrolling or inlining, since
> > they generate far more code to look through, and include the flags used.
> >
> > Note - it is possible that you've hit a bug in the compiler here
somewhere,
> > since you should not need to explicitly re-enable the interrupts. Can
you
>
> i just looked at the gcc internals and the posted source, looks fine on
> first sight.
>
> it generates hwmul code in the following form:
>
> push r2
> dint
> nop
> .....
> pop r2
>
> which means it should restore your previous interrupt setting, but it
> uses two bytes on the stack.
>
> chris
I have not had any problems with interrupts and the hardware multiplier, but
there must be *some* reason why the original poster's code was leaving
interrupts disabled. However, without clearer code and smaller generated
assembly, it is hard to tell whether there is some obscure bug in the
compiler (doubtful, but not impossible) or whether it lies somewhere else
(perhaps interrupts were already disabled before his function was called, or
maybe he has stack overflows, etc.)
David
>
> > cut down the code to a minimum that still displays the interrupt
problem,
> > and then post the code, generated assembly, and information about the
> > compiler version and compile flags?
>
