Does anyone have a list of the hidden AVR commands?
Perhaps they have been elmininated in newer chips
the hidden commands
Author
Message
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29038 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
:roll:
Level: Raving Lunatic
Joined: Fri. May 4, 2007
Posts: 3749 View posts
Location: Geelong Australia, Home of the "Cats"
The silicon wafer contains commands which are only known by the Illuminati and if we told you what they are, we would have to kill you. So please do not ask, as we are kind gentleman.
Yes, you have seen it on the US one dollar note and it makes no sense to me either!
Attachment(s):
Level: Raving Lunatic
Joined: Sun. Aug 13, 2006
Posts: 7472 View posts
Location: Bellingham, WA - USA
Do you mean the unassigned/undocumented opcodes?
RMS - release magic smoke
DCS - disconnect clock source
RHH - request help on homework
WPJ - wait for profundity from J-----n
CAF - construct algorithm on the fly
etc.
If I tell you any more, Lee will have to come over and shoot you.
zbaird wrote:
RMS - release magic smoke
But watch, this command can only be used in timed sequences.
Within four clock cycles the RIP command must follow. :)
Peter
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97016 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Where does one use the infamous HCF in this sequence? Is it what triggers RMS or does it have to smoulder a bit before HCF can be used?
Also the CMFRM (COMEFROM) instruction was very useful for debugging to see, what happens prior the fault.
Peter
Quote:
Where does one use the infamous HCF in this sequence? Is it what triggers RMS or does it have to smoulder a bit before HCF can be used?
The usual requirement of them having to be done within 4 clock cycles?
Quote:
Does anyone have a list of the hidden AVR commands?
Perhaps they have been elmininated in newer chips.
I know there were some "hidden" opcodes in '51 uCs, but never heard about these in AVRs.
Anyway, lets suppose your question is simply imprecise and you want us to guess what you meant by saying "hidden commands".
You meant:
- A) AVR instruction set does not take 65536 opcodes into consideration. It is not an ARM, no ISR is raised then the core faces unknown instruction. All these opcodes are treated "in undefined way" which means "hell knows what happens". Do not expect them to be nops!
B) Several opcodes can give same results (act exactly the same), although only one is documented, like "sbrs r31,7" works like ".dw 0xFFFF". Can these have any practical value, when the documented version can be used?
C) You found there are words which do not present any reasonable instruction in some AVR binaries.
.db "Hello world" explains that.
D) All AVRs have proprietary debugging protocols. Perhaps you are looking for those AVR commands? This is not easy but several people state they managed to crack protocols (search "Mk2 clone").
E) Not all IO resources of AVRs labeled as "reserved" are not implemented. Perhaps you think some can be reused if you knew their location?
F).....
?
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97016 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
The "hidden" instructions in a lot of processors are usually a side effect of incomplete instruction decode so I guess there may be similar in the AVR unless it completely decodes all active bit patterns and rejects the rest as "nop" (seems unlikely). Already the famous case of the 0xFFFF opcode has been explored at length. I think someone said there was something like 15,000 of the 65,000 opcodes that did not have a documented effect so I guess one just needs a program that tries each in turn and does a full comparison of the machine state both before and after to document what they do?
No on the newer once with more LPM's etc. there is only in the ballpark of 100 unused instructions, if you don't count the 256 opcodes for nop.
And don't expect any fancy instructions to come up. Some bit will just be don't care, so some instructions have more opcodes.
It's not like the Z80 and 6502 that have plenty of extra instructions.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97016 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Oh well if it's just 100 it should be fairly easy. I think for an easy life what I'd do is use a C program on the PC to generate a binary file with every 16 bit pattern from 0 to 65535, hex2bin it, feed it to an AVR disassembler and grep for "invalid opcode" (or however it is reported) then filter those to a separate test harness that tries each one in turn and analyses the before/after machine state on a real piece of silicon using OCD.
clawson wrote:
AAAhh 99, of course, the old "Obscure Code Decoder" trick. Nearly missed it by that much! (with apologies to Maxwell Smart)
... using OCD.
Level: Raving Lunatic
Joined: Sun. Aug 13, 2006
Posts: 7472 View posts
Location: Bellingham, WA - USA
The OP must have read my post in this thread:
https://www.avrfreaks.net/index.p...
I should have been more active on this forum. You guys have way to much time on your "busy schedules", but have a heck of a lot of fun as well :)
Brutte wrote:
I know there were some "hidden" opcodes in '51 uCs
Thats impossible, since only one unused opcode exist.
And this opcode 0xA5 act like a NOP.
Peter
Quote:
Thats impossible, since only one unused opcode exist.
You are right, I think it was Z80.
Quote:
if you don't count the 256 opcodes for nop.
And not including "34 alternatives of clr" type of totally unused instructions it seems AVRs effectively have 13 or 12 bit wide program bus.
Quote:
feed it to an AVR disassembler and grep for "invalid opcode"
I wonder how many log2(#asm opcodes) (opcodes, so that ldi ZL,1 is different than ldi ZL,2) AVR programmers effectively use. Asm, GCC, IAR and other. Without PROGMEM of course.
Perhaps 12. Or even less.
zbaird wrote:
RMS - release magic smoke
You should not use it.
Electronics work on smoke, if the smoke comes out. It's broken!
:P
To Brutte:
remember that there are 4096 rjmp instructions (same for rcall).
all the direct instructions ANDI ORI etc each take 1024.
mov add .... reg to reg take all 1024
etc..
So in a "normal" AVR (not a 1200 etc.) there are more than 60000 usefull opcodes used.
Quote:
I wonder how many log2(#asm opcodes) (opcodes, so that ldi ZL,1 is different than ldi ZL,2) AVR programmers effectively use. Asm, GCC, IAR and other. Without PROGMEM of course.
Perhaps 12. Or even less.
From a Mega1280 app, ~64k of code plus about 8k of constants (primarily menu strings):
RESOURCE USE INFORMATION ------------------------ Notice: The register and instruction counts are symbol table hit counts, and hence implicitly used resources are not counted, eg, the 'lpm' instruction without operands implicitly uses r0 and z, none of which are counted. x,y,z are separate entities in the symbol table and are counted separately from r26..r31 here. .dseg memory usage only counts static data declared with .byte ATmega1280 register use summary: r0 : 474 r1 : 73 r2 : 93 r3 : 81 r4 : 80 r5 : 49 r6 : 52 r7 : 26 r8 : 26 r9 : 29 r10: 13 r11: 10 r12: 144 r13: 13 r14: 102 r15: 16 r16: 643 r17: 938 r18: 293 r19: 339 r20: 258 r21: 124 r22: 586 r23: 518 r24: 369 r25: 255 r26:4138 r27:1653 r28: 197 r29: 1 r30:8684 r31:3130 x :1045 y :4169 z : 523 Registers used: 35 out of 35 (100.0%) ATmega1280 instruction use summary: .lds : 0 .lds.l: 0 .sts : 0 .sts.l: 0 adc : 205 add : 247 adiw :1241 and : 55 andi : 230 asr : 0 bclr : 0 bld : 80 brbc : 0 brbs : 0 brcc : 6 brcs : 0 break : 0 breq : 514 brge : 16 brhc : 0 brhs : 0 brid : 0 brie : 0 brlo : 248 brlt : 19 brmi : 4 brne : 581 brpl : 2 brsh : 178 brtc : 3 brts : 0 brvc : 0 brvs : 0 bset : 0 bst : 1 call :2599 cbi : 18 cbr : 1 clc : 0 clh : 0 cli : 10 cln : 0 clr : 372 cls : 0 clt : 12 clv : 0 clz : 0 com : 40 cp : 174 cpc : 170 cpi :1056 cpse : 0 dec : 22 des : 0 elpm : 0 eor : 10 fmul : 0 fmuls : 0 fmulsu: 0 icall : 12 ijmp : 0 in : 57 inc : 22 jmp : 285 ld : 650 ldd :2234 ldi :3757 lds :1943 lpm : 76 lsl : 76 lsr : 34 mov : 834 movw : 872 mul : 212 muls : 0 mulsu : 0 neg : 3 nop : 0 or : 95 ori : 55 out : 84 pop : 102 push : 102 rcall : 167 ret : 273 reti : 14 rjmp :1178 rol : 75 ror : 22 sbc : 23 sbci : 401 sbi : 25 sbic : 13 sbis : 16 sbiw : 179 sbr : 3 sbrc : 16 sbrs : 144 sec : 0 seh : 0 sei : 8 sen : 0 ser : 1 ses : 0 set : 65 sev : 0 sez : 0 sleep : 0 spm : 0 st :2181 std : 627 sts : 993 sub : 22 subi : 670 swap : 28 tst : 22 wdr : 7 Instructions used: 75 out of 117 (64.1%) ATmega1280 memory use summary [bytes]: Segment Begin End Code Data Used Size Use% --------------------------------------------------------------- [.cseg] 0x000000 0x011ed2 65162 8264 73426 131072 56.0% [.dseg] 0x000200 0x0020fe 0 7678 7678 8192 93.7% [.eseg] 0x000000 0x000a71 0 2673 2673 4096 65.3%
Quote:
brhc : 0 brhs : 0
:twisted:
Quote:
pop : 102 push : 102
Nice stack management :P
Quote:
brhc : 0 brhs : 0
That one of the first AVR's made if all the way to production with a half bit error show how rare it's used!
I remember the undocumented instructions on the MCS6502 seemed to be the result of the current sinking devices on the bus being able to sink more current than the current sourcing devices. Not the kind of instruction I would want to bet my career upon.
By the way, zbaird, you let out "RCS" -Reconnect Clock Source", An instruction that has never been successfully tested!
theusch wrote:
call :2599
rcall : 167
ret : 273
Sorry for the very old post review, but I can not just let it past without notice.
2599+167 calls generating two bytes (PC) being pushed into stack, and only 273 returns... uhm...
That is exactly what AVR assembly programmers do for a living... strange magical things... 
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97016 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
What are you talking about? I could have a function called delay: with one RET that is called from 15 different places (so 15 (R)CALL), what's unusual about that?
clawson wrote:
What are you talking about? I could have a function called delay: with one RET that is called from 15 different places (so 15 (R)CALL), what's unusual about that?
Nothing unusual, I use to do that too.
Recently while developing 23 bits precision sin()/cos() and log2(), in AVRasm I started to pay more attention to clock cycles than instruction count, and confirmed CALL/RET increase substantially code timing mostly in multibyte mul/div. In the past, with Flash size restriction (mostly at the time of 8051 and eproms), I used to squeeze bytes using lots of subroutines, at that time there was no other way, now with 128kBFlash life is easier...
Talking about AVR instruction set, and instruction count, AVR would be nicer with "ADCB Rd" (Add CBit to Rd, Increment Rd if Carry Set, updating SReg bits for cascating), it can replaced by "ADC Rd,Rs" but it always require a expended register RS with zero contents. The counterpart "SBCB RD" isn't necessary since we have "SBCI Rd, 0" even considering only on upper registers. Another good gift would be "STW"/"LDW" (Store/Load Word).