On a list file, *.lss, generated by AS6, one can notice the following lines:
"ATmega8A" instruction use summary:
.lds : 0 .sts : 0 adc : 17 add : 13 adiw : 0 and : 0
... etc.
I wonder what could be the difference between the two instructions .LDS and LDS (.STS and STS).
I couldn’t find about “.LDS” or “.STS” on any help file I have.
Also searching “.LDS” or “.STS” leads to “LDS” or “STS” instead.
Thank you.
Kerim
The "lss" in this case is presumably from Atmel Aseembler 2 not the C or C++ compilers? (AFAIK the GNU binutils don't write such info in their LSS files). I imagine it's a bug in the assembler and should simply read "lds" not ".lds"
if you do add use of LDS to your code does the ".lds" figure increase. If yes then clearly it's just a fault in the annotation.
What compiler? Codevision, perhaps?
He said AS6 so it's got to be one of the AVR8 tools in that I guess and as I don't think it's the C or C++ compiler I'm guessing it must be the assembler.
(and this output does look like the same thing you see at the end of a Codevision build which is basically invoking the same assembler)
If I was near AS6/AS7 I'd try it - but I'm not so I won't.
What compiler? Codevision, perhaps?
Interesting. CV does indeed use those...
</p> <p>ATmega328P instruction use summary:<br /> .lds : 0 .lds.l: 0 .sts : 0 .sts.l: 0 adc : 40 add : 45 <br /> adiw : 138 and : 2 andi : 26 asr : 0 bclr : 0 bld : 3 <br /> brbc : 0 brbs : 0 brcc : 2 brcs : 0 break : 0 breq : 130 <br /> brge : 21 brhc : 0 brhs : 0 brid : 0 brie : 0 brlo : 24 <br /> brlt : 28 brmi : 0 brne : 247 brpl : 4 brsh : 14 brtc : 2 <br /> brts : 0 brvc : 0 brvs : 0 bset : 0 bst : 2 call : 486 <br /> cbi : 28 cbr : 1 clc : 0 clh : 0 cli : 5 cln : 0 <br /> clr : 65 cls : 0 clt : 3 clv : 0 clz : 0 com : 9 <br /> cp : 33 cpc : 49 cpi : 389 cpse : 0 dec : 12 des : 0 <br /> eor : 4 fmul : 0 fmuls : 0 fmulsu: 0 icall : 8 ijmp : 0 <br /> in : 12 inc : 2 jmp : 28 ld : 87 ldd : 218 ldi :1308 <br /> lds : 264 lpm : 11 lsl : 47 lsr : 9 mov : 170 movw : 70 <br /> mul : 9 muls : 0 mulsu : 0 neg : 13 nop : 0 or : 7 <br /> ori : 6 out : 39 pop : 6 push : 6 rcall : 72 ret : 63 <br /> reti : 7 rjmp : 372 rol : 45 ror : 12 sbc : 19 sbci : 61 <br /> sbi : 28 sbic : 5 sbis : 12 sbiw : 43 sbr : 2 sbrc : 15 <br /> sbrs : 21 sec : 0 seh : 0 sei : 3 sen : 0 ser : 13 <br /> ses : 0 set : 3 sev : 0 sez : 0 sleep : 0 spm : 0 <br /> st : 338 std : 139 sts : 236 sub : 16 subi : 127 swap : 0 <br /> tst : 7 wdr : 3 </p> <p>
Under the hood CV uses avrasm2.exe from Atmel. Currently v2.1.30
The "lss" in this case is presumably from Atmel Aseembler 2
But then it would be .LST, right? [I suppose there are options to specify the output file name]
Interesting. CV does indeed use those...
??? Why do you say it "uses" them, when the use count is zero?
Remember that that "CV" listing is just the assembler listing.
I peeked at the Instruction Set manual, and don't have any hints. The "16 bit" LDS perhaps?
I poked a .LDS into a test program. The assembler objects, as it sees the leading . and assumes a directive. That was with an AVR8 target. Same with Xmega and brain-dead.
LOL -- a good question. Been in ASM2 since at least 2010...
https://www.avrfreaks.net/comment...
... but not in a 2007 build with AVRASM ver. 2.1.9
... nor with 2.1.17
... but does appear in a 2009 build with 2.1.30.
Is this not simply that the author of this opcode display from Asm2 has added leading '.' to those very common opcodes so they sort to the start of the list in this alpha sorted list of opcodes?
I ask again: if you use just a "normal" LDS or STS then does that count increase at the top of this display?
I ask again: if you use just a "normal" LDS or STS then does that count increase at the top of this display?
Again, the counts for the dot variants are zero.
I forgot to say that I write my codes on AS6 in assembly only.
It seems after reading your remarks that the addition of these non-existent instructions on the summary list is just a human error.
Thank you all for your help and time.
Kerim
How odd - wonder what the author had in mind? Or is it simply a bug?
This has been poked at before. In https://www.avrfreaks.net/forum/u... zbaird found an instruction decode for the mystery instructions, but the 'Freaks that poked at it couldn't come up with a good resolution.
The timing is roughly when the brain-dead was introduced. (Tiny10 datasheet rev. A is dated April-2009)
