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

[Joerg Wunsch]

As Thomas K wrote:

> does anybody know, what's happen, if a real controller get a invalid 
> opcode?

The Verilog source code might give some more insight.  Unfortunately, 
even to someone with access to that source code, it's probably going 
to be a tedious job to find it out.

Even then, there are basically two options: if the source code makes 
clear decisions (e.g. by means of a "default" statement, or by 
explicitly coding that pattern), it can be said for sure.  If the 
source code simply omits some cases, the step where it is turned into 
actual logic (the synthesization) can optimize unspecified cases, 
yielding unpredictable behaviour (it could e.g. be different on an 
ATmega16 from an ATmega8 even though both used the same source code).

However, the avrfreaks article I mentioned claims that early 
descriptoins of the AVR instruction set used one "X" bit in the SBRS 
instruction, thus leading to a clear decision towards decoding 0xFFFF 
into that SBRS, provided all later implementations did not delete that 
internally from the Verilog code.

However, unless someone has kept such an early document (I'm afraid I 
didn't; the article mentioned a databook from 1997), this is hard to 
tell nowadays.

For reference, here is the test program mentioned in that article:

-----------code--------------------------------------------
.include "m163def.inc"

rjmp    reset       ; jump over the next few lines

; PORTB will only output 0x0F if the mcu reaches this point
after_reset:        ; flash location 0x0001
ldi     r16, 0xFF
out     DDRB, r16   ; set PORTB as output
ldi     r16, 0x0F
out     PORTB, r16  ; output 0x0F
rjmp    PC          ; loop forever


reset:
ldi     r31, 0x80   ; // set bit 7 in r31

; now the mcu will start executing 0xFFFFs
; starting from address 0x0007
;
;nop
;
; uncommenting the NOP will cause the 0xFFFFs
; to start from 0x0008 and the mcu will never
; execute the PORTB code
-----------code--------------------------------------------

Depending on that NOP line, if 0xFFFF is decoded as SBRS r31,7, port B 
will output 0x0F or not.

We might try this on as many AVRs as possible, including more exotic 
ones.

> Maybe: "--invalid-opcode=(ffnop|break|abort)"
> 
> ffnop - FF FF interpreted as NOP without any message (or SBRS r31,7)
> break - behaviour like breakpoint with message
> abort - (the default) abort simulation with a message

I could live with that.  I think the latter cases could be combined: 
if the simulator instance runs against a debugger, then break, if it 
runs standalone, abort.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)