Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader

[Albrecht Frenzel]

> 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" <address@hidden>
> > An: "Joerg Wunsch" <address@hidden>, address@hidden
> > 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
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/simulavr-devel