[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite

From: Paulo Marques
Subject: Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.
Date: Wed, 20 Apr 2011 13:06:24 +0100
User-agent: Thunderbird (X11/20090817)

Georg-Johann Lay wrote:
> Paulo Marques schrieb:
>> Georg-Johann Lay wrote:
>>> A program that goes wild does such weird things, even if there is *no*
>>> RAM there :-)
>>> For some variations of the test case avrtest detects a stack overflow,
>>> but for the exe you find attached avrtest does not see a stack overflow.
>> Ah! If this only happens for really bad bugs, we could either place a
>> timeout there or use a command line argument to disable stdin altogether
>> (maybe even exiting with ABORT in case the code tries to read stdin).
> A command line option to deactivate stdin would be good. avr is not on a
> hosted environmant, there is nowhere input could come from.

Actually on a real AVR you can redirect the input/output to a serial
port (for instance) and have all the stdio functions work.

For avrtest this is even better. You can write code like:

  printf("number of iterations:\n");
  scanf("%d", &iterations);

and run it on a linux terminal just like any other command line C
program. With some binfmt_misc tricks we could probably get away with
running avr code directly from the command line ;)

> ABORT is a good idea, with an appropriate "reason".
> Besides that, avrtest could abort on:
> - reading from any reserved location
> - writing to any reserved location (except the virtual ports EXIT_PORT,
> this includes read/writes to GPRs via their memory address.

Yes, having a "noio" parameter to run testsuite tests would be nice.

For normal programs, it is nice to sometimes let the program write to
peripheral address ports (even if they do nothing) just to be able to
test a piece of code in the middle of a real program without having to
change the program too much.

> To check for reserved access code like this should perform well
> int a = ((int) address) -32;
> if (a < 0
>     || (reserved_mask & (1 << a)))
>   abort();
> or just initialize a small lookup table for reads/writes.

I think the code for read is just:

if (address >= 0x20 && address < 0x60)

which translates to:

if (((unsigned) address - 0x20) < 0x40)

but maybe the compiler is smart enough to do the optimization, without
the code obfuscation.

> The writer will already have handled the virtual ports, so the LUT for
> reals/writes may be same.

Yes, it is just the same test but after the switch statement.

However, this is a really, really hot-path for the simulator. One of the
things avrtest is good at is speed. It is not as fast as JIT-compile
speed, but it is able to do a 100MHz avr on a Pentium4-3.0GHz, i.e., on
a decent desktop machine you can do "faster than real" avr simulation.

So maybe instead of a command line argument, we should use a defined
constant and just have the makefile compile a different version for the
"unsafe" version.

Maybe some benchmarks could show if this is worth it or not...

Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"I haven't lost my mind -- it's backed up on tape somewhere."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]