Re: [ECOS] twothreads.c not working correctly on ARM AEB1

[Jonathan Larmour <jlarmour at redhat dot co dot uk>]

[ stuff about twothreads delay not being computed correctly, traced to
dodgy % behaviour ]

javelina wrote:
>
> As a sanity check on the bad behavior of the % operator, I wrote a tiny program to
> isolate the problem
> 
>//////////////////////////////////////////////
> 
> #include <stdio.h>
> 
> int main(void)
> {
>    int i;
>    int m;
>    for (i=0; i < 21; i++) {
>        m = i % 5;
>        printf("%d %d\n", i, m);
>    }
> }
>//////////////////////////////////////////////
> 
> The ouput looks like:
> 
> (gdb) continue
> Continuing.
> 0 0
> 1 1
> 2 2
> 3 3
> 4 4
> 5 5
> 6 6
[snip] 
> So it realy does look like a mod operator problem.  Let me know what you think.

Aha! I found it, and it's interesting. Basically, for the AEB, you *must*
compile with -mcpu=arm7di as used in the example makefile. However, you
didn't compile this program, nor twothreads with this option. Whenever I
compile the above with -mcpu=arm7di it works, and without it, it behaves as
you saw. 

The reason is that without -mcpu=arm7di, the compiler will default to
-mcpu=arm7tdmi, which assumes you have a fast multiplier unit, which the
arm7di (as used on the AEB) doesn't.

As a result the compiler uses the "smull" instruction, which fails silently
- unfortunately the ARM doesn't raise an exception when this instruction is
not supported.

So compile with -mcpu=arm7di and all will be well.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault