Re: [Simulavr-devel] Whats to do on execution of "illegal instruction"

[Petr Hluzín]

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



-- 
Petr Hluzin