Hello folks
I am sorry to arrive this late at the party. Thankfully my two cents
do not change much.
IMHO simulators are more useful to detect and report possibly buggy
situations. Simulators can provide a way to override the default
behavior. In fact the error message might indicate to user how to
change the behavior so the user would not need to google (quick) or
search documentation (slow).
Michael Hennebry does not suggest to have every invalid opcode
individually configurable - if I understand correctly. He suggests to
distinguish 0xFFFF opcode from other invalid opcodes - because the
value 0xFFFF can plausibly be intended, while others are even less
likely. Therefore a command-line option would be sufficient. (I do not
like weird configurability.) If user wants to get crazy and configure
everything, then Python has all the power he would dream of. We could
even extend it to allow creating custom instruction object witch
callbacks to Python+Tcl code and allow it to be set into flash array -
although I doubt anyone here wants this capability.
In the mean time, people trying to simulate bootloaders can:
(a) attach gdb and execute $pc=0x7e00 command
(b) add one instruction to .vectors sections, not to the usual .text
section (note 1)
(c) we can add code to read fuses from the ELF file. (Note 2)
Klaus wrote:
It is maybe also an idea to isolate the decoding stage
completely from simulavr core sources. This opens the
decoder engine to other cores. Maybe simulavr become
a startpoint for other cores like arm?
A new architecture would need a new AvrDevice-like class anyway, all
the difficult or error-prone code is AVR-specific. The only things
that could be reused are SystemClock, GdbServer and partially
AvrDevice::Step(). And there are ARM simulators already, simulavr has
no advantage.
If the decoder interface is isolated it can be adapted to be scriptable.
It is already callable from scripts.
=====
Note 1: The avr-libc's interrupt table object has a weak linkage, I think.
Note 2: The OP user did add fuses to the ELF file, right? If not, why
he expects simulavr would handle his case at all?
On 7 February 2016 at 11:03, Klaus <address@hidden> wrote:
Hi,
I think, translating ff ff to NOP is not a good idea. I would prefer
executing a SBRS r31,7 and the option as
--invalid-opcode=(execute|break|abort)
And this flags must be set for each illegal opcode. As Michael states, he
has a need to differentiate between different opcodes.
A config file is not necessary.
Which then results to have a endless list of options on the command line.
How should the user store this complex options?
The need to modify simulavr's code should be strictly avoided; it would
make it looking like an endless construction area.
simulavr is already an endless construction area! If you see all the ways
you can interact with simulavr you can get an idea how many interfaces are
already implemented. This story will never end.
If you decide to want to have a single additional command line option, feel
free to implement this. You can provide the patch in the patch area of the
project. If it works for you and maybe others, we can make this a branch.
The chance to have only a single command line option for all illegal
instructions looks not very common for all users. So I did not prefer such a
solution. But it is easy to have branches in git and keep them alive while
merging from master time by time.
Because I prefer a "hack" solution with changing simply one line in
decoder.cpp on the users need, I will not spend time for this option and
yes, I did not want tons of additional command line options. Maybe decoder
changes can be made scriptable in the future. It is maybe also an idea to
isolate the decoding stage completely from simulavr core sources. This opens
the decoder engine to other cores. Maybe simulavr become a startpoint for
other cores like arm? If the decoder interface is isolated it can be adapted
to be scriptable. This avoids endless command line options and also avoids
config files. The python and tcl interface is a good place for hacking such
user requirements for each individual user without changing the core again
and again. As you sad, an endless construction area.
I take a look how we can change the memory decoder and provide some "non
real hardware related" special opcodes which can replace real opcodes.
I can also support you, if you want to change the simulavr code for your
personal needs. It is also no problem to maintain a branch for your needs if
this is useful for other users too. I can also give you some hints how you
can do this on your machine for your own. git is really easy and helpful for
exactly doing this work.
Regards
Klaus
_______________________________________________
Simulavr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/simulavr-devel