Hi again,
I want to start a discussion how we should implement a "illegal instruction"
execution. Current behavior is simply stopping simulavr.
Silently terminating simulavr on ffff is the worst solution.
this depends on the use case and that is what I ask for.
On the other hand, simulavr has an additional UART for debug output
If the test environment is not connected to it does not help.
A real controller doesn't "terminate" if it runs into ffff
A real controller does "something" on all illegal instructions. And I could not find out
what really happens on a real device. So in any case, running on any illegal instruction must be
handled in some "special" way.
So we have a lot of test environments where external scripts/progs have some
expectations on the behavior of simulavr. E.g. running as a regression check
for some code we expect termination with non zero return value. If running in
verlilog we expect termination, because there is maybe not any other connection
to any additional (user) interface. If simply running a trace we expect
termination instead of a endless trace output.
So the problem is to find a solution which fits for most needs.
Simply ignoring the problem and continue the code is not a solution and executing
"nop" is exactly that.
So there is a need to configure the behavior of a "illegal instruction". In gdb
session execution like running on a trap/break is OK. At minimum the instruction must not
increment the program counter so that we step in place then, break and investigate the
current state of code execution.
But what happens if gdb interface is used as test environment connection and is
not able to deal with breakpoints because the test itself did not use them?
There is no general "good" solution. And in gdb mode simply use breakpoint
infrastructure is also not fitting all needs.
Lets start a list of configurable solutions:
What should happen on "illegal instruction" execution in simulavr:
1) stop simulavr with retrun code !=0 ( as yet imlemented )
2) act like running on a breakpoint, do not increment program counter
3) report a line on trace output
4) ....
I would collect all proposals and try to find which does not break all existing
environments. But I don't know all the use cases simulavr actually supports.
So please add some ideas! Keep in mind that program access to non existing
ram/eeprom/flash address is the same problem here.
Thanks
Klaus