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
