Room for 2 more instructions?

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

Seems like a load word and store word would be real useful. Someone was smart when they made move word. Any opcodes left?

Imagecraft compiler user

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

Quote:
Any opcodes left?

If I give you an opcode will you implement it?

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

I'll just send my buddy Ulf a msg on comp.arch.embedded and he can walk it over to the VPs office.

Imagecraft compiler user

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

Such an instruction would take several opcodes. At the very least you would want to be able to specify the register pair that you want the value loaded into. For any register pair, that would make 16 opcodes (R0, R2, R4, etc). Then the same for store. I suppose that you could limit it to the upper 8 register pairs, that would reduce it to 8 opcodes each. But I don't really see the point. At best it would reduce 16 bit access from 4 words to 2 words and 4 cycles to 3 cycles. For the amount of time that it would be used it probably wouldn't be worth it.

Regards,
Steve A.

The Board helps those that help themselves.

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

Looks like it would cut the size of programs using a lot of ints and longs by about half though? How many opcodes are unused?

Imagecraft compiler user

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

Well, Bob, since you asked so nicely (twice) here's most of them. I notice I didn't include a few which are listed at the end; there may be more. This was from an old project I was playing with (but never got off the ground) back in the early Pleistocene.

    nop                   ; 0000 0000 0000 0000
    movw   r17:r16,r1:r0  ; 0000 0001 dddd rrrr
    muls   r16,r17        ; 0000 0010 dddd rrrr
    mulsu  r18,r19        ; 0000 0011 0ddd 0rrr
    fmul   r16,r17        ; 0000 0011 0ddd 1rrr
    fmuls  r18,r19        ; 0000 0011 1ddd 0rrr
    fmulsu r20,r21        ; 0000 0011 1ddd 1rrr
    cpc     r31,r1        ; 0000 01rd dddd rrrr
    sbc    r1,r31         ; 0000 10rd dddd rrrr
    lsl    r15            ; 0000 11dd dddd dddd
    add    r30,r31        ; 0000 11rd dddd rrrr
    cpse    r1,r31        ; 0001 00rd dddd rrrr
    cp      r1,r30        ; 0001 01rd dddd rrrr
    sub   r1,r31          ; 0001 10rd dddd rrrr
    rol    r15            ; 0001 11dd dddd dddd
    adc    r1,r2          ; 0001 11rd dddd rrrr
    tst   r5              ; 0010 00dd dddd dddd (see and rd,rd)
    and    r3,r4          ; 0010 00rd dddd rrrr
    eor    r1,r31         ; 0010 01rd dddd rrrr
    clr     r15           ; 0010 01rd dddd rrrr (see eor rx,rx)
    or     r1,r31         ; 0010 10rd dddd rrrr
    mov    r1,r31         ; 0010 11rd dddd rrrr
    cpi     r17,0xff      ; 0011 kkkk dddd kkkk
    sbci   r17,0x20       ; 0100 kkkk dddd kkkk
    subi  r17,0x23        ; 0101 kkkk dddd kkkk
    ori    r17,0x23       ; 0110 kkkk dddd kkkk
    sbr    r22,0x12       ; 0110 kkkk dddd kkkk
    andi   r16,0x81       ; 0111 kkkk dddd kkkk
    ld     r22,Z          ; 1000 000d dddd 0000 (i)
    ld     r18,Y          ; 1000 000d dddd 1000 (i)
    st    Z,r4            ; 1000 001r rrrr 0000 (i)
    st    Y,r4            ; 1000 001r rrrr 1000 (i)
    lds    r15,0x100      ; 1001 000d dddd 0000 (+ addr)
    ld     r23,Z+         ; 1001 000d dddd 0001 (ii)
    ld     r24,-Z         ; 1001 000d dddd 0010 (iii)
    lpm    r15,Z          ; 1001 000d dddd 0100 (ii)
    lpm    r16,Z+         ; 1001 000d dddd 0101 (iii)
    ld     r19,Y+         ; 1001 000d dddd 1001 (ii)
    ld     r20,-Y         ; 1001 000d dddd 1010 (iii)
    ld     R15,X          ; 1001 000d dddd 1100 (i)
    ld     R16,X+         ; 1001 000d dddd 1101 (ii)
    ld     R17,-X         ; 1001 000d dddd 1110 (iii)
    pop    r16            ; 1001 000d dddd 1111
    sts   0x1234,r1       ; 1001 001d dddd 0000 (+ addr)
    push   r17            ; 1001 001d dddd 1111
    st    Z+,r5           ; 1001 001r rrrr 0001 (ii)
    st    -Z,r6           ; 1001 001r rrrr 0010 (iii)
    st    Y+,r5           ; 1001 001r rrrr 1001 (ii)
    st    -Y,r6           ; 1001 001r rrrr 1010 (iii)
    st    X,r1            ; 1001 001r rrrr 1100 (i)
    st    X+,r2           ; 1001 001r rrrr 1101 (ii)
    st    -X,r3           ; 1001 001r rrrr 1110 (iii)
    sec                   ; 1001 0100 0000 1000
    ijmp                  ; 1001 0100 0000 1001
    sez                   ; 1001 0100 0001 1000
    sen                   ; 1001 0100 0010 1000
    sev                   ; 1001 0100 0011 1000
    ses                   ; 1001 0100 0100 1000
    seh                   ; 1001 0100 0101 1000
    set                   ; 1001 0100 0110 1000
    sei                   ; 1001 0100 0111 1000
    bset    5             ; 1001 0100 0sss 1000
    clc                   ; 1001 0100 1000 1000
    clz                   ; 1001 0100 1001 1000
    cln                   ; 1001 0100 1010 1000
    clv                   ; 1001 0100 1011 1000
    cls                   ; 1001 0100 1100 1000
    clh                   ; 1001 0100 1101 1000
    clt                   ; 1001 0100 1110 1000
    cli                   ; 1001 0100 1111 1000
    bclr   5              ; 1001 0100 1sss 1000
    ret                   ; 1001 0101 0000 1000
    icall                 ; 1001 0101 0000 1001
    reti                  ; 1001 0101 0001 1000
    sleep                 ; 1001 0101 1000 1000
    break                 ; 1001 0101 1001 1000
    wdr                   ; 1001 0101 1010 1000
    lpm                   ; 1001 0101 1100 1000 (i)
    spm                   ; 1001 0101 1110 1000
    com     r31           ; 1001 010d dddd 0000
    neg    r31            ; 1001 010d dddd 0001
    swap  r7              ; 1001 010d dddd 0010
    inc    r1             ; 1001 010d dddd 0011
    asr    r30            ; 1001 010d dddd 0101
    lsr    r16            ; 1001 010d dddd 0110
    ror    r16            ; 1001 010d dddd 0111
    dec    r1             ; 1001 010d dddd 1010
    jmp    63             ; 1001 010k kkkk 110k (+ addr)
    call    63            ; 1001 010k kkkk 111k (+ addr)
    adiw   ZH:ZL,63       ; 1001 0110 kkdd kkkk
    sbiw   r25:r24,31     ; 1001 0111 kkdd kkkk
    cbi     15,5          ; 1001 1000 aaaa abbb
    sbic   31,3           ; 1001 1001 aaaa abbb
    sbi    31,5           ; 1001 1010 aaaa abbb
    sbis   15,5           ; 1001 1011 aaaa abbb
    mul    r1,r31         ; 1001 11rd dddd rrrr
    in     r31,63         ; 1011 0aad dddd aaaa
    out    31,r15         ; 1011 1aar rrrr aaaa
    ldd    r25,Z+63       ; 10q0 qq0d dddd 0qqq (iv)
    ldd    r21,Y+31       ; 10q0 qq0d dddd 1qqq (iv)
    std   Z+31,r7         ; 10q0 qq1r rrrr 0qqq (iv)
    std   Y+31,r7         ; 10q0 qq1r rrrr 1qqq (iv)
    rjmp   63             ; 1100 kkkk kkkk kkkk
    rcall  63             ; 1101 kkkk kkkk kkkk
    ser    r17            ; 1110 1111 dddd 1111
    ldi    r31,63         ; 1110 kkkk dddd kkkk
    brcs   63             ; 1111 00kk kkkk k000
    brlo    63            ; 1111 00kk kkkk k000
    breq   lbl            ; 1111 00kk kkkk k001
    brmi    63            ; 1111 00kk kkkk k010
    brvs    63            ; 1111 00kk kkkk k011
    brlt    63            ; 1111 00kk kkkk k100
lbl: brhs    63           ; 1111 00kk kkkk k101
    brts    63            ; 1111 00kk kkkk k110
    brie    63            ; 1111 00kk kkkk k111
    brbs   5,63           ; 1111 00kk kkkk ksss
    brcc   63             ; 1111 01kk kkkk k000
    brsh    63            ; 1111 01kk kkkk k000
    brne    63            ; 1111 01kk kkkk k001
    brpl    63            ; 1111 01kk kkkk k010
    brvc    63            ; 1111 01kk kkkk k011
    brge   63             ; 1111 01kk kkkk k100
    brhc   63             ; 1111 01kk kkkk k101
    brtc    63            ; 1111 01kk kkkk k110
    brid    63            ; 1111 01kk kkkk k111
    brbc   5,63           ; 1111 01kk kkkk ksss
    bld    r1,2           ; 1111 100d dddd 0bbb
    bst     r17,5         ; 1111 101d dddd 0bbb
    sbrc   r16,5          ; 1111 110r rrrr 0bbb
    sbrs   r15,3          ; 1111 111r rrrr 0bbb

;    eicall
;    eijmp
;    elpm
    cbr     r31,0x12      ; same as andi with k complemented

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

bobgardner wrote:
How many opcodes are unused?
I counted 1682.

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

Quote:
I counted 1682.

Is that with or without the eicall, eijmp, and elpm instructions? And did anyone look and see if there are any others not in the list?

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 eicall, eijmp, and elpm.

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

I have a list of unused codes at home (with a couple of newer (xmega) ones missing). I'll look at it after work.

Regards,
Steve A.

The Board helps those that help themselves.

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

What about DES opcodes?

    1.Do you mean only 2^16-1682 codes modify anything more than a PC++ (not mentioning nop)? 2.Did anybody JTAG-ed step by step, bit by bit all the rest of 1682 op-codes to see if there are some undocumented ones in AVR cores?
    3.Which code would be the most beneficial from your application point of view?
    4.Is it a linear combination of the existing ones you consider (inw, outw, ldw, stw) or something special?

No RSTDISBL, no fun!

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

Yikes. Remind me to buy Alf a beer if he ever comes to Orlando. Good thing the boss doesn't want me to design a risc cpu...

Imagecraft compiler user

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

bobgardner wrote:
Seems like a load word and store word would be real useful. Someone was smart when they made move word. Any opcodes left?

I understand where you're coming from. The code fragment that probably bugs me more than any other is something like

lds r18, addr
lds r19, addr+1
...do something with 16-bit val
sts addr+1, r19
sts addr, r18

But if they haven't put in a word load/save by now, I wouldn't expect it to happen. Maybe the hangup is getting two memory accesses in one instruction, I don't know.

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

Well, I got 1699 unused bit patterns (rather than 1682) which boil down to 41. I only used the list above, so no uniquely xmega instructions (which didn't exist when that list was made). This could be buggy, of course. A programmer wrote it.

1)  0000 0000 0000 00x1
2)  0000 0000 0000 0x10
3)  0000 0000 0000 x10x
4)  0000 0000 0000 x111
5)  0000 0000 000x 10xx
6)  0000 0000 000x 1110
7)  0000 0000 00x1 0xxx
8)  0000 0000 00x1 110x
9)  0000 0000 00x1 1111
10) 0000 0000 0x10 xxxx
11) 0000 0000 0x11 10xx
12) 0000 0000 0x11 1110
13) 0000 0000 x10x xxxx
14) 0000 0000 x111 0xxx
15) 0000 0000 x111 110x
16) 0000 0000 x111 1111
17) 0000 0000 10xx xxxx
18) 0000 0000 1110 xxxx
19) 0000 0000 1111 10xx
20) 0000 0000 1111 1110
21) 1001 000x xxxx x011
22) 1001 00xx xxxx 1000
23) 1001 001x xxxx 0x11
24) 1001 001x xxxx 010x
25) 1001 001x xxxx 0110
26) 1001 001x xxxx 1011
27) 1001 010x xxxx 0100
28) 1001 010x 000x 1011
29) 1001 0100 0x1x 10x1
30) 1001 0100 x10x 10x1
31) 1001 0100 10xx 10x1
32) 1001 0100 111x 10x1
33) 1001 0101 0x1x 100x
34) 1001 0101 0x1x 1011
35) 1001 0101 010x 100x
36) 1001 0101 010x 1011
37) 1001 0101 1x0x 10x1
38) 1001 0101 1x10 10x1
39) 1001 0101 1x11 100x
40) 1001 0101 1x11 1011
41) 1111 1xxx xxxx 1xxx

I dropped these into the list and reran the program that generated it, and it appears this is all there is - all opcodes taken with these in the mix.

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

Last Edited: Wed. Jun 16, 2010 - 03:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for seconding my opinon kk. I wouldnt care if it was 2 cycles as long as it was atomic. There would still be a space win. Maybe AVRs are like laundry soap. After a good 10 year run they add the words "New Improved" to the box and put the ads in the trade mags again.

Imagecraft compiler user

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

Memorable quotes for
The 5,000 Fingers of Dr. T. (1953) More at IMDbPro »
ad feedbackDr.

Terwilliker: Is it atomic?
Bart Collins: Yes sir, VERY atomic!

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

Uncle Bob: Seems like a load word and store word would be real useful.

Dr. Strangelove: Ve haf ze technology. All ve lack iz ze vill to do so!

(or something along those lines)

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

AVRs SRAM have the option of faster sequential access, like "rcall" which stores 2 bytes of PC to two consecutive locations of SRAM, and it takes 3clks only, so stw or ldw could in theory use the same scheme to access 2 bytes of SRAM in less than 4 clks, if implemented. And it could be atomic, like rcall.

No RSTDISBL, no fun!

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

I would pursue reimplementation of the SEX instruction from 1802.

That would relieve the pressure from the 3 index (pointer) registers.

JW

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

Lets write our own core!

No RSTDISBL, no fun!

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

If you really want to make 16 bit extentions why not do it the hole way! implement a flag (I don't mind if you kill the H sfr flag) there when high will make most opcodes 16 bit, I don't care if they take the same clk as the two 8 instructions they replace ex:

Add r16,r20
would do
ADD r16,r20 and ADC r17,r21

LD r0,Z+
would do
LD r0,Z+ and r1,Z+

etc.

The only thing is that they have to be made atomic.

This will not take any extra opcodes.

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

Quote:
This will not take any extra opcodes.
But it will take a whole lot of extra silicon.
Quote:
will make most opcodes 16 bit
I think that you will find that "most" would dwindle down to "a handful" when you consider how many opcodes work. You can immediately eliminate all the immediate opcodes (hardwired to 8 bit values), all the branch instructions and CALL, RET and JMP variants (16 bit operation makes no sense), MOV (already has a 16 bit), all the set and clear SREG bit opcodes, all the I/O opcodes (SBI, CBI, IN, OUT, SBIC, SBIS), miscellaneous opcodes (BREAK, NOP, DES, SLEEP.

Regards,
Steve A.

The Board helps those that help themselves.

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

I see someone mentioned this thread on comp.arch.embedded.

Imagecraft compiler user

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

What you suggest is to make an 8-bit AVR an 16-bit AVR with 8-bit data bus.

Quote:
I don't mind if you kill the H sfr flag

I disagree. I suppose on 4-bit uCs the 8-bit operations are made much the same way as 16-bit operations on 8-bit uCs (like AVRs). When discarding SREG_H you will not be able to use nibble arithmetics, which is atomic the same way as movw is on bytes.. The idea about useless SREG_H is because neither ANSI C nor GCC support nibble and bit variables.

Did anybody experience the use of BRHS/BRHC/SEH/CLH in a compiled C program (without explicit use of asm("::"))?

No RSTDISBL, no fun!

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

Quote:
But it will take a whole lot of extra silicon

No I will not make any 16bit instructions just a 2 instruction sequencer like the ADIW instruction that take 2 clk because it's two 8 bit add's.

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

Quote:
just a 2 instruction sequencer
Which will take silicon to accomplish. Your not going to get anything for free.

Regards,
Steve A.

The Board helps those that help themselves.

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

Then you have to define

Quote:
whole lot
no it's not free but you could save a lot of flash that take some space aswell.

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

I have worked with a 4bit samsung controller it had a lot of opcodes that went to a table of 2 normal opcodes for this "new" one. It has a lot of functions that make the program small( fast was not the goal) if you repeat an instruction it only do the first and make the rest to nop's so

L0:
ld a,10
L1:
ld a,50
l2:
ld a,30

Wil leave a with 10, 50 or 30 depending on witch label you jump to.

An other nice instruction is RETS that is a skip RET so the first instruction after the return will be skiped, that very handy when functions return true or false.

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

Quote:
I got 1699 unused bit patterns (rather than 1682) which boil down to 41.
My count was less than that (1666). I haven't had time to look at the differences. I do wonder though how you arrived at your 1-20 in your list. It really just boils down to no opcodes below 0x0100 except for NOP at 0x0000. I do think that you are probably missing the DES opcode from the xmegas (which takes it down 16), and there is a second SPM intruction added at some point. That still leaves 16 difference.

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi wrote:
My count was less than that (1666).
I thought I would try to double check my count. Well, things actually look much more complicated than I expected. It looks that the same opcodes are used for different instructions on different parts. I had no idea! For example, the STS 16 bit instruction, which I have not seen before, overlaps the STD Z range.

Eugene

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

yes it's stupid to make 256 NOP's and not just define it as mov r0,r0 or something like that.

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

And now when we are at it is

mov r0,r0

a used instruction ? I have never seen it used ;)

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

Counting the "free" opcodes left, please do not forget the Math Extension Module (MEXT) opcodes - they should have probably eaten most of the "free" space though not being implemented in all AVR cores.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Quote:
Wil leave a with 10, 50 or 30 depending on witch label you jump to.

Cunning!

I like the idea, it does not even need an opcode and cannot be easily substituted (this is like "skip if previous instruction is much the same as the current one"). It exploits the fact that such sequence of similar instructions can be condensed in one, but simply:

ldi x,10
ldi x,50
ldi x,30

is irrational from the programmer point of view on AVR.

Quote:
RETS that is a skip RET so the first instruction after the return will be skiped, that very handy when functions return true or false

Clever! I want it in AVR!
You must have to modify a STACK or make an POP,POP,INC,IJMP to do that on AVR. I sometimes use PUSH, PUSH, RET instead of IJMP, but AVR simulator has a bug and it crashes or displays errors (stack underflow) in such situations (already placed it on Studio 5 wishlist).

Good ideas!

No RSTDISBL, no fun!

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

Quote:
I do wonder though how you arrived at your 1-20 in your list. It really just boils down to no opcodes below 0x0100 except for NOP at 0x0000.

Of course you're correct, Steve. I generate all the illegals, then run them through a kludge of an algorithm to compress them. It obviously needs a little tweaking.

I think it should generate something like:

0000 0000 0000 0001
0000 0000 0000 001x
0000 0000 0000 01xx
0000 0000 0000 1xxx
0000 0000 0001 xxxx
0000 0000 001x xxxx
0000 0000 01xx xxxx
0000 0000 1xxx xxxx

instead of the first 20 it did generate. What you get is what you pay for, I guess. I think (hope) those 20 expand to the same thing these 8 do, however.

I substituted these 8 for the previous 20 and reran it, and these do seem to get everything.

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

Somebody made a decode chart like that a few years back--I'd wager that old thread has some counts in it.

Lee

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:
yes it's stupid to make 256 NOP's
But there aren't 256 NOP's. It is one NOP and 255 unused opcodes.
Quote:
think (hope) those 20 expand to the same thing these 8 do
Well, your 1 through 20 add up to 255, so your at least half way there ;)

Regards,
Steve A.

The Board helps those that help themselves.

Last Edited: Thu. Jun 17, 2010 - 02:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But there aren't 256 NOP's. It is one NOP and 256 unused opcodes.

Again nothing for free I bet you that there is 256 nops , that will fit into the pattern of the other instructions, if it was one of a kind instruction it should be placed near instructions like IJMP that is decodet full as a instruction.

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

Brutte wrote:
What you suggest is to make an 8-bit AVR an 16-bit AVR with 8-bit data bus.

You could say so, but 16-bit data is so useful in the real world (and such a fundamental C requirement) that it may be a good place to go.

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

But isn't it an 8-bit uC? The set of instructions should have made it an excellent 8-bit machine, and not a mediocre 16-bit one. It will be lost with any other 16-bit machine in terms of the silicone size and speed which will not need an extra 8/16 bit switch.
All the idea reminds me a Thumb/ARM construction.

No RSTDISBL, no fun!

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

ezharkov wrote:
the same opcodes are used for different instructions on different parts
Sorry for hijacking the thread. Does anybody know what parts use the "STS (16-bit)" instruction? Is there a document that defines instructions implemented on any given part, besides the datasheet PDF?

Eugene

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

Quote:
Does anybody know what parts use the "STS (16-bit)" instruction?
Certainly any AVR that has SRAM will use it, so it would be much easier to make a list of which ones don't use it. A quick search makes that: tiny11, tiny12, tiny15, tiny28, 90s1200.

The xmegas are the wildcard in this as they are the ones where the STS and STD overlap.

Regards,
Steve A.

The Board helps those that help themselves.

Last Edited: Thu. Jun 17, 2010 - 03:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Certainly any AVR that has SRAM will use it, so it would be much easier to make a list of which ones don't use it.
Look at the description of the STS instructions in Atmel's doc0856.pdf (revision 0856H–AVR–07/09). There are two of them, one 32 bit, one 16 bit. Which one is used where?

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

tiny28 doesnt have any ram I think?

Imagecraft compiler user

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

AVRASM.chm help file wrote:
AVR8L Instruction Set

Devices using the AVR8L CPU: ATtiny10, ATtiny20, ATtiny40.

The AVR8L CPU core is a low-cost version of the AVR, and lacks certain features found in regular AVR, most notably:

Register file is 16 registers instead of 32 (R16-R31). The assembler will produce an error message if registers R0-R15 are used.

Instruction set is reduced, see table below. Notice that the LDS/STS instructions are different from regular AVRs, it is a 1-word instruction with an addressing range of 128 bytes. Also notice that the LPM instruction is eliminated; the Flash memory is mapped into data memory and can be read by means of using the LD instruction.


Core version can be find in the Partdescriptionfiles directory (xml files), or in the assembler includes.

JW

[EDIT]> grep AVR8L *.xml

ATtiny10.xml:    AVR8L_0
ATtiny10.xml:    AVR8L
ATtiny20.xml:    AVR8L_0
ATtiny20.xml:    AVR8L
ATtiny4.xml:    AVR8L_0
ATtiny4.xml:    AVR8L
ATtiny40.xml:    AVR8L_0
ATtiny40.xml:    AVR8L
ATtiny5.xml:    AVR8L_0
ATtiny5.xml:    AVR8L
ATtiny9.xml:    AVR8L_0
ATtiny9.xml:    AVR8L
Last Edited: Thu. Jun 17, 2010 - 03:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, now I see. I would bet that it is only the new 6 pin chips that have this (tiny10 and the like).

Regards,
Steve A.

The Board helps those that help themselves.

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

wek wrote:
... AVR8L Instruction Set ...

Thanks Jan.

I wish they would create a separate PDF for this and not put mix incompatible sets into a single document.

Eugene

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

ezharkov wrote:
I wish they would create a separate PDF for this and not put mix incompatible sets into a single document.
I think it's quite OK to have it in a single document, if it is properly organized. Say, a table with instruction variants versus core version would go a long way...

Drifting off topic, but I'd also like to see documented the various versions of peripherals, and then these assigned to individual AVR models through the XML files, say. Would help to write universal libraries.

Jan

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

Saw this msg from Ulf Samuelson on camp.arch.embedded dated today.... it might be in the avr32 section here, but I havent read all of it to see
=========================================================

There will soon be a major new release of tools,
merging 8 and 32 bit AVRs toolsets.

UC3A0/1 - Networking/communication/Audio
UC3A3 - Focus on Audio
UC3B/D - General purpose Micro
UC3C - Motor control with Event System and Floating Point.
UC3L - Real low power

Imagecraft compiler user

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

Quote:
Ok, now I see. I would bet that it is only the new 6 pin chips that have this (tiny10 and the like).
tiny20 is 14 pin and tiny40 is 20 pin.
The limitation is not the amount of IO but of RAM!

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

Quote:
AVRASM.chm
Is this available anywhere on the net? I have an old version of the studio (4.15), and I do not really want to install the latest just to see the new version of the file. The one that came with 4.15 does have an AVR8L section, but it does not look right to me. There are LD/ST Y+ Y- Z+ Z- links, but they all point to an X section.

Eugene

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

The current version of that help file in AVR Studio 4.18 SP2 still behaves like that.

Note that most variants of the LD/ST X/Y/Z instructions do not overlap with the 16-bit LDS/STS. It's only the LDD Z+D (load from z pointer with displacement) and STD Z+D (store to z pointer with displacement) which overlap. And all of those displacement variants are omitted from the AVR8L core.

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

Quote:
The limitation is not the amount of IO but of RAM!
I was not saying the 6 pin chips because of IO, but of the core that is in them. And it is not a matter of how much RAM there is in them. The RAM in the tiny 20 is 128 bytes, but the data space is much larger than this. The STS (16 bit) opcode can address the first 128 bytes of the data space, but only 64 bytes of that is RAM, the rest is I/O.

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi wrote:
Quote:
The limitation is not the amount of IO but of RAM!
I was not saying the 6 pin chips because of IO, but of the core that is in them. And it is not a matter of how much RAM there is in them. The RAM in the tiny 20 is 128 bytes, but the data space is much larger than this. The STS (16 bit) opcode can address the first 128 bytes of the data space, but only 64 bytes of that is RAM, the rest is I/O.

In fact, the ATtiny20's LDS/STS instructions have a range of 128 bytes, but according to the datasheet, those 128 addresses are actually remapped to run from 0x0040 to 0x00BF -- encompassing the entire on-chip SRAM, to the exclusion of the I/O space.

However, there are lots of other parts with 128 bytes or less of SRAM, and yet they use the full 32-bit LDS/STS instead of the 16-bit versions. Eg: ATtiny13.

My bet is that the 16-bit LDS/STS was chosen as a convenient cost-cutting and code-size-shrinking optimization specifically tailored to the reduced number of general-purpose CPU registers -- R16..R31 instead of R0..R31 -- in the AVR8L core.

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

The instruction set datasheet is confusing in this opcode. It goes on about:

Quote:
For parts with SRAM, the data space consists of the Register File, I/O memory and internal SRAM
Only later on does it say the address is really mapped to above 0x40 (which takes it to SRAM).

Regards,
Steve A.

The Board helps those that help themselves.