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. ;-) _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
