can someone explain what is the intention to have behave different in
simulation then in real hardware?
A real controller doesn't "terminate" if it runs into ffff, so
somulavr currently doesn't behave like real hardware.
On the other hand, simulavr has an additional UART for debug output
- that's also not, what real hardware does, but very useful.
So why not use the undefined instruction ffff as a debug aid, since
it mostly points to serious problems? This would give a chance to
inspect the machine state.
Silently terminating simulavr on ffff is the worst solution.
Albrecht
On 05.02.2016 12:34, Klaus Rudolph wrote:
Hi,
can someone explain what is the intention to have behave different in
simulation then in real hardware? What is the intended use case of an illegal
instruction or simulate undefined behavior? I can't follow at this point.
I can only see my use case in the moment which is as follows:
Write, compile, link program
Verify & Validate on simulation
use simulation as regression tool for code maintenance
If I see that my code runs into a empty flash region, I will stop immediately
with debugging, I simply must fix my code.
Maybe you have another situation or you plan very different things. So please
give me an idea what is the scenario behind that idea to run over illegal
instructions.
>From simulation side is very easy to exchange any illegal instruction to nop, but is
that the intention and why? If we plan to do this change we must support the current
implementation. Maybe a command line switch to extend the instruction set for
"undefined" instruction for personal use? Changing the default behavior is not
acceptable for my use cases.
Regards
Klaus
Gesendet: Freitag, 05. Februar 2016 um 10:57 Uhr
Von: "Albrecht Frenzel" <ajfren...@web.de>
An: "Joerg Wunsch" <joerg_wun...@uriah.heep.sax.de>, simulavr-devel@nongnu.org
Betreff: Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader
As the AVR (undocumentedly) treats opcode ffff as a NOP, I think
the simulator could even just continue.
That's a good idea, but why not make it configurable: in normal mode
it is NOP, but on demand ffff can act as BREAK?
Albrecht
On 05.02.2016 08:02, Joerg Wunsch wrote:
As Albrecht Frenzel wrote:
The strange thing: sometimes pc gets loaded with the correct pc
0x7e00 and it is possible to step through the code using the same
.elf-file.
You can always set the current PC address in GDB before proceeding:
set $pc = 0x7e00
Regarding Illegal opcode 'ff ff': wouldn't it be better to simply
stop simulavr instead of terminating? That would give a chance to
investigate.
As the AVR (undocumentedly) treats opcode ffff as a NOP, I think
the simulator could even just continue. There are possible
scenarios where this feature could be used deliberately, e. g.
by including a patch area in the code that is simply run through
as long as it is ffff but which can be written later on to
include additional features.
_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel