AVR Freaks

I'm not making it hard for no reason, I'm writing an assembler...

If I generate the wrong bytes, then the program won't work.

I have +/- figured out how to assemble this instruction. I'm

going to write some examples for future reference and self-doc.

Note: I'm using NOPs to move the BREQ instruction up and

down. I could be using any other instruction (CMP for example).

The output using a label:

Reversing F9F3, because it is in little-endian, it becomes F3F9

F3F9 is 1111 0011 1111 1001 in binary.

The BREQ instruction opcode is defined as 1111 00kk kkkk k001:

That means the value of k is 1111111 in binary. This binary

number  represents  7F  in  hex  and 127  in  decimal.  The

instruction description says that k is represented in the two's

complement form.

To get a number's two's complement, all bits logical values

must be reversed and then added 1. Let's reverse the process:

(~address) + 1 = k

(~address) + 1 = 0111 1111

~address = 0111 1111 - 1

~address = 111 1110

address = 000 0001

In this example the output is positive 1. Why isn't it -1 (111111)?

Another possible result would be 1000 0001, which would be 129

in decimal and would be wrong. Let's move to the next one:

Applying the same logic:

E1F3 is in little-endian, reversing the bytes it becomes F3E1.

The binary value of F3E1 is 1111 0011 1110 0001. The value

of k is 1111100 in binary (or 124 in decimal).

(~address) + 1 = k

(~address) + 1 = 111 1100

~address = 111 1100 - 1

~address = 111 1011

address = 000 0100 (4 in decimal)

Or the address can be 1000 0100, considering it an 8-bit

number. 1000 0100 in decimal is 132, that means the first

value is probably the correct one. It's confusing that the

value is 4 instead of -4...

The last example - jumping forward:

Repeating the process again:

09F0 becomes F009 = 1111 0000 0000 1001 in binary.

The value of k is 0000001 in binary.

(~address) + 1 = k

(~address) + 1 = 0000001

~address = 000 0001 - 1

~address = 000 0000

address = 111 1111, which is -1

First I thought k was an 8-bit number, but it isn't!

And the sign bit shouldn't be flipped apparently.

A program with a single BREQ 64 instruction compiles.

Or any program with a single BREQ k instruction where

k >= 0 && k <= 64. The reason may be because in the

Microchip Assembler k must be in the two's complement

form. This also explains why NOP NOP BREQ -1 NOP NOP

doesn't compile.

(~address) + 1 = k

(~address) + 1 = -1

~address = -2 = 000 0010

address = 111 1101 = 125 in decimal (out of range)

The problem is solved by now, thanks for the patience 😂.

@westfw Got it, thanks 😄!

@david.prentice Thank you,

I've already implemented labels yesterday... The problem

was that the BREQ instruction operand must be in two's

complement form... First I thought k was an offset between

-64 and 63, that's why the unit tests weren't passing 🙁.

@avrcandies Thanks! I'm only writing it for fun and to

learn more...