BRNE jump range, is this an ERROR in the Atmel AVR instruction datasheet ?

[MathWizard]

I'm decoding the opcodes from a little blink program on an ATTiny13A. And in the atmel-0856-avr-instruction-set-manual datasheet on page 54,  for the "BRNE k", Branch If Not Equal command, it lists the # of Words k, forwards or backwards, the PC can jump to if the  Z flag was 0. PC <-- PC +k +1

But they say k is from -64 to +6, so is that really supposed to be -64 to +63 ? And so a signed SXX XXXX number ? My code has
BRNE 124d
So I think that's k = -4 = 111 1100

I don't see it mentioned in the revisions, also they have the table of contents at the END, I've never seen that before.

[voltsandjolts]

The answer is in the image you posted.

[magic]

It's correct in my version

Rev. 0856I–AVR–07/10

But LOL, they really managed to screw it up in later revisions. The answer is of course -64<=k<64, as with other conditional branch insns.

[westfw]

The newer manual (DS40002198A) doesn't have the error...)

[MathWizard]

Yeah I should have put this in the other ATTiny thread I had. This stuff is addictive. I've been making a model of this MCU/program, in the OpenOffice spreadsheet, it doesn't really do binary or hex.  I've made clocked, full BJT ALU's in LTSpice before, so for real automation I might try some of this in LTS too. Before downloading some basic MCU sim program. Now I can't wait to make some 4 or 8bit MCU with all BJT's.

I'm using all NAND logic, so like open collector. With only using decimal 1,0 , 1-X=1 or 0 is an inverter, and the AND gate is X*Y=0 or 1. So I've made some register's, full 8-bit adders/ALU's, w/ inverted Carry flags, and 2's compliment were wanted, that matches the datasheet so far.  And the Status SREG, for all the ALU flags.

For now, I'm just making copies/new GP reg's and ALU for each instruction of interest, like the compare w/ carry instructions.

So I can see in this blink program, how it made the millis function counter, using some compare commands and subtractions, and BRNE, to count down 255*165*14 ~590,000, and 255*82*7 ~146,000. I'll have to make a small # of  cycles in the spreadsheet MCU, to see what it really does.


There's a bunch of POKE commands in the middle of the program, IDK much about the stack counter, or how all that will tie in to the "while" command, and the bitshift it does at the start, using compares, and more BRNE's. It starts witting numbers into the data SRAM too.


I expected the program to be shorter, I think I'm using the blink example in ArdIDE. Soon I'll have to try writing bare-metal Assembly for blink ON/OFF. The way they do it is probably fine, but IDK what all the rest of the middle code must be for yet.

#include <avr/io.h>
  #include <util/delay.h>

  int main(void)
  {
    DDRB = 1<<3; // port B3, ATtiny13a pin 2
    PORTB = 0x0;

    while (1)
    {
      PORTB = 1<<3; // port B3, ATtiny13a pin 2
      _delay_ms(500);
      PORTB = 0X0;
      _delay_ms(250);
   

[westfw]

I expected the program to be shorter, I think I'm using the blink example in ArdIDE.

You can find a lot of analyses of Arduino code in various places, explaining some of the "unexpected bloat."
For simple programs (ie without Arduino), people are usually surprised by the interrupt vector table (~100 bytes) and C runtime initialization (~50 bytes)

My long-ago post:https://community.element14.com/products/arduino/w/documents/7889/analysis-of-an-empty-arduino-sketch

[44kgk1lkf6u]

How long a binary did you get?  I compiled with avr-gcc (Fedora 14.1.0-1.fc40) 14.1.0, with the options -std=gnu2x -Os -mmcu=attiny13 -DF_CPU=1'000'000.  The binary is 80 bytes long with no store instructions.

Code: [Select]

Disassembly of section .text:

00000000 <__vectors>:
   0: 09 c0        rjmp .+18      ; 0x14 <__ctors_end>
   2: 0e c0        rjmp .+28      ; 0x20 <__bad_interrupt>
   4: 0d c0        rjmp .+26      ; 0x20 <__bad_interrupt>
   6: 0c c0        rjmp .+24      ; 0x20 <__bad_interrupt>
   8: 0b c0        rjmp .+22      ; 0x20 <__bad_interrupt>
   a: 0a c0        rjmp .+20      ; 0x20 <__bad_interrupt>
   c: 09 c0        rjmp .+18      ; 0x20 <__bad_interrupt>
   e: 08 c0        rjmp .+16      ; 0x20 <__bad_interrupt>
  10: 07 c0        rjmp .+14      ; 0x20 <__bad_interrupt>
  12: 06 c0        rjmp .+12      ; 0x20 <__bad_interrupt>

00000014 <__ctors_end>:
  14: 11 24        eor r1, r1
  16: 1f be        out 0x3f, r1 ; 63
  18: cf e9        ldi r28, 0x9F ; 159
  1a: cd bf        out 0x3d, r28 ; 61
  1c: 02 d0        rcall .+4      ; 0x22 <main>
  1e: 16 c0        rjmp .+44      ; 0x4c <_exit>

00000020 <__bad_interrupt>:
  20: ef cf        rjmp .-34      ; 0x0 <__vectors>

00000022 <main>:
  22: 88 e0        ldi r24, 0x08 ; 8
  24: 87 bb        out 0x17, r24 ; 23
  26: 18 ba        out 0x18, r1 ; 24

00000028 <.L2>:
  28: 88 bb        out 0x18, r24 ; 24
  2a: 2f e9        ldi r18, 0x9F ; 159
  2c: 36 e8        ldi r19, 0x86 ; 134
  2e: 91 e0        ldi r25, 0x01 ; 1

00000030 <.L1^B1>:
  30: 21 50        subi r18, 0x01 ; 1
  32: 30 40        sbci r19, 0x00 ; 0
  34: 90 40        sbci r25, 0x00 ; 0
  36: e1 f7        brne .-8      ; 0x30 <.L1^B1>
  38: 00 c0        rjmp .+0      ; 0x3a <L0^A>

0000003a <L0^A>:
  3a: 00 00        nop
  3c: 18 ba        out 0x18, r1 ; 24
  3e: e3 e2        ldi r30, 0x23 ; 35
  40: f4 ef        ldi r31, 0xF4 ; 244

00000042 <.L1^B2>:
  42: 31 97        sbiw r30, 0x01 ; 1
  44: f1 f7        brne .-4      ; 0x42 <.L1^B2>
  46: 00 c0        rjmp .+0      ; 0x48 <L0^A>

00000048 <L0^A>:
  48: 00 00        nop
  4a: ee cf        rjmp .-36      ; 0x28 <.L2>

0000004c <_exit>:
  4c: f8 94        cli

0000004e <__stop_program>:
  4e: ff cf        rjmp .-2      ; 0x4e <__stop_program>


[westfw]

The binary is 80 bytes long

the code shown isn't "the Arduino blink example"; Arduino will likely add some additional overhead.

(Hmm.  "microcore" compiles the standard blink example to 90 bytes, which is better than I thought it would be!
Differences seems to be: initialize TCNT0, Turn on Interrupts, and delay() is implemented as a loop around _delay_ms(1))

(IIRC, there was another ATtiny13 "core" that was substantially less optimized than microcore.)

[MathWizard]

IDK for sure were I got this blink code, I might have copy/pasted it, from some ATTiny tutorial. But it's from 0-87, so 88 WORDS, 178 Bytes of program flash.

I just did up another spreadsheet to show what I think the prog does overall. But it doesn't lead to any of the middle stuff. This spreadsheet doesn't load the REG's and do all the ALU math, besides the program counter.

I don't know much about the STACK, so I thought for a while that maybe the DDRB 1<<3, and the "while" command  was doing some sort of PWM, overtop of the LED blink, to save power. This thing has bitwise operations, I expected a direct leftshift command. So I thought somehow all that was related to the RAM addresses that get used with the Store function and Xreg/XPointer, and the RCALL routine.

But no I don't see  anything like that. And DDRB is just for setting the port as input or output, so that's a bad way to try PWM. And they only ever write R1=0 into the start of RAM locations, so yeah I need to see some Stack and SP examples.


But does this look about right ? Yeah IDK what all the middle code is for yet, nothing seems to lead there, if I got this right. It looks messy in a table so here's a pic

[westfw]

This thing has bitwise operations, I expected a direct leftshift command.

The bitshifts, since they have constants for both arguments, happen at compile time and won’t appear in the binary.