Unknown "dot" instructions

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking over the listing for an assembler file this morning and noticed something strange. At the end of the file the assembler totals up the instructions used, and I saw at the top of this list two unknowns - ".lds" and ".sts". I tried using a couple of these dot-instructions into the file to see how they assembled, but they gave me "unknown directive" errors. Does anyone know what they are?

(Apologies if this has been covered before. The forum search function strips off the dot and just returns millions of "lds" and "sts" results)

AVRASM ver. 2.1.42  C:\AVR\New Host\ghost.asm Thu Dec 30 10:05:00 2010



RESOURCE USE INFORMATION
------------------------



ATmega168 instruction use summary:
.lds  :   0 .sts  :   0 adc   :   7 add   :   8 adiw  :   5 and   :   0 
andi  :   6 asr   :   0 bclr  :   0 bld   :   0 brbc  :   0 brbs  :   0 
brcc  :   4 brcs  :   7 break :   0 breq  :  30 brge  :   0 brhc  :   0 
brhs  :   0 brid  :   0 brie  :   0 brlo  :   0 brlt  :   0 brmi  :   0 
brne  :  37 brpl  :   0 brsh  :   0 brtc  :   0 brts  :   0 brvc  :   0 
brvs  :   0 bset  :   0 bst   :   0 call  :   0 cbi   :  16 cbr   :  32 
clc   :   0 clh   :   0 cli   :   0 cln   :   0 clr   :  34 cls   :   0 
clt   :   0 clv   :   0 clz   :   0 com   :   0 cp    :   2 cpc   :   0 
cpi   :  35 cpse  :   2 dec   :  25 eor   :   3 fmul  :   0 fmuls :   0 
fmulsu:   0 icall :   0 ijmp  :   3 in    :   6 inc   :  15 jmp   :  26 
ld    :  12 ldd   :   0 ldi   : 204 lds   :  57 lpm   :   9 lsl   :   5 
lsr   :   4 mov   :  10 movw  :   6 mul   :   3 muls  :   0 mulsu :   0 
neg   :   0 nop   :   2 or    :   4 ori   :   3 out   :  26 pop   :  20 
push  :  20 rcall :  95 ret   :  95 reti  :   5 rjmp  : 144 rol   :   3 
ror   :   1 sbc   :   0 sbci  :   0 sbi   :  13 sbic  :   0 sbis  :   0 
sbiw  :   1 sbr   :  20 sbrc  :  24 sbrs  :  16 sec   :   0 seh   :   0 
sei   :   1 sen   :   0 ser   :   0 ses   :   0 set   :   0 sev   :   0 
sez   :   0 sleep :   0 spm   :   0 st    :  38 std   :   0 sts   : 117 
sub   :   1 subi  :   5 swap  :   1 tst   :  12 wdr   :   1 
Instructions used: 54 out of 113 (47.8%)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sniffing around in the assembler 2 executable reveals this:

 std 100x001rrrrrxxxx 10q0qq0dddddqqqq Ry+q
 ldd 100x000dddddxxxx 1001001rrrrr0000kkkkkkkkkkkkkkkk
 .sts 1001000ddddd0000kkkkkkkkkkkkkkkk
 .lds 10101AAAssssAAAA
 .sts.l 10100AAAddddAAAA
 .lds.l 1110KKKKddddKKKK
 ldi  00000001ddddrrrr
 movw 001011rdddddrrrr

(with nothing close in the directive symbol table).

For what it's worth, which may not be much. Interpretation and tracking down the bit patterns is left as an exercise for the (advanced) student.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like they refer to the 16-bit opcode versions of the lds and sts instructions, although that assembler 2 data is confusing. According to the AVR instruction manual, lds(16-bit) starts with 10100 and sts(16-bit) starts with 10101, which is opposite from what I think I'm seeing in that listing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good find. They could be 16 bit versions for processors like the Tiny4 with short memories and only 16 registers. I see from the Tiny4 instruction summary that it does LDS/STS in one cycle, where it normally takes two, so maybe the assembler substitutes automatically depending on the processor definitions file.

Ok, I found them in the latest instruction document, but there are no dots, so it must be an automatic substitution.

kk6gm, perhaps the manual is wrong - it wouldn't be the first typo found in an Atmel document.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
1010 0kkk dddd kkkk

is the op code for LDS for the Tiny10 etc. (AVR8L, aka "brain dead"). That doesn't match your .LDS, does it?

The "full" LDS is

32-bit Opcode:
1001 000d dddd 0000 kkkk kkkk kkkk kkkk 

Something is a bit off. Are those messages you decoded, Chuck? Perhaps they are not quite right.

But there is some similarity to the AVR8L stuff.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is just from a dump of the executable, replacing nonprinting characters with blanks, tossing single and double printables, and collapsing blank runs. It shouldn't be taken to mean much in a literal sense since an enormous amount of info has been removed. I was just trying to see if .lds/.sts were defined like the other opcodes.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With "unsigned int frog;" at address 0x48, a Tiny10 build with CodeVision gives the following AVRASM2 .LST fragment

                 ; 0000 005A         frog++;
00003c a1e8      	LDS  R30,_frog
00003d a1f9      	LDS  R31,_frog+1
00003e 5fef      	SUBI R30,LOW(-1)
00003f 4fff      	SBCI R31,0xFF
000040 a9e8      	STS  _frog,R30
000041 a9f9      	STS  _frog+1,R31

from which one can decode the single-word variations of LDS and STS. However, the opcode summary gives those counts in the LDS/STS spots and not the ones being discussed here:

ATtiny10 instruction use summary:
.lds.l:   0 .sts.l:   0 adc   :   0 add   :   0 and   :   0 andi  :   0 
asr   :   0 bclr  :   0 bld   :   0 brbc  :   0 brbs  :   0 brcc  :   0 
brcs  :   0 break :   0 breq  :   0 brge  :   0 brhc  :   0 brhs  :   0 
brid  :   0 brie  :   0 brlo  :   0 brlt  :   0 brmi  :   0 brne  :   1 
brpl  :   0 brsh  :   0 brtc  :   0 brts  :   0 brvc  :   0 brvs  :   0 
bset  :   0 bst   :   0 cbi   :   0 cbr   :   1 clc   :   0 clh   :   0 
cli   :   1 cln   :   0 clr   :   1 cls   :   0 clt   :   0 clv   :   0 
clz   :   0 com   :   0 cp    :   0 cpc   :   0 cpi   :   0 cpse  :   0 
dec   :   1 eor   :   0 icall :   0 ijmp  :   0 in    :   1 inc   :   0 
ld    :   0 ldd   :   0 ldi   :  13 lds   :   4 lsl   :   0 lsr   :   0 
mov   :   0 neg   :   0 nop   :   0 or    :   0 ori   :   0 out   :  27 
pop   :   0 push  :   0 rcall :   0 ret   :   0 reti  :   0 rjmp  :  14 
rol   :   0 ror   :   0 sbc   :   0 sbci  :   1 sbi   :   0 sbic  :   0 
sbis  :   0 sbr   :   0 sbrc  :   0 sbrs  :   0 sec   :   0 seh   :   0 
sei   :   0 sen   :   0 ser   :   0 ses   :   0 set   :   0 sev   :   0 
sez   :   0 sleep :   0 st    :   1 std   :   0 sts   :   4 sub   :   0 
subi  :   1 swap  :   0 tst   :   0 wdr   :   1 
Instructions used: 15 out of 100 (15.0%)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That just introduces two new mystery opcodes - .lds.l and .sts.l - though it does reveal that in Chuck's dump the mnemonic comes after the string, not before, and that the Tiny10 LDS compiles to what appears to be .lds.l

10100AAAddddAAAA
 .lds.l


00003c a1e8 (10100_001_1110_1000)  LDS  R30,_frog 

Opcode 10100, address 001_1000, register 1110

The register 1110 is recognizable enough as ZL, 30 - 16 for a 16-reg AVR, but I can't see how 001_1000 corresponds to address 0x48. According to the instruction manual there's an offset of 0x40, so I would read this as unsigned(frog) is at 0x58.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

According to the instruction manual there's an offset of 0x40, so I would read this as unsigned(frog) is at 0x58.


But there are 16 registers mapped to SRAM space as well? (Makes my head hurt.)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But there are 16 registers mapped to SRAM space as well? (Makes my head hurt.)

Of course, I forgot that. That accounts for the offset of 16. Also I recall the Flash is mapped to SRAM space, at 0x4000, which can also be accessed with LDS - so the compiler/assembler must select what version of LDS to use based on the context.

If this is a headache, then designing the chip logic to retain big-AVR compatibility must have been head-exploding.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Also I recall the Flash is mapped to SRAM space, at 0x4000, which can also be accessed with LDS - so the compiler/assembler must select what version of LDS to use based on the context.

...which could account for the (to this point) confusing ...
Quote:

.sts 1001000ddddd0000kkkkkkkkkkkkkkkk

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... Except that's the bog standard 32 bit LDS instruction, for 32 registers and a 64k address space. Still doesn't explain the dot mystery or why the dot instructions are totalled separately by the assembler. Though... ".lds.l" could indicate a LONG lds, which is why the count is 0 in your example. But wait - there can be no LONG sts (.sts.l) because writing Flash as data doesn't work. Now my head hurts too.