[WISHLIST] Suugestion for ASM Improvement

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

Don't know if this is appropriate forum as my suggestion is for the ASM compiler and not for AVR Studio per se.

Here is one useful suggestion that shouldn't be hard to implement:

The compiler I am migrating from allow the use of binary constants as follows:

LDI R16,0b0001_0010 ;Note the great use of the "_" to break the
;byte into two nybbles

It sure is a LOT easier on the eyes than starring at:

LDI T16,0b00010010
LDI T17,0b01010010
LDI T18,0b11010010
LDI T19,0b11101001

Thanks for your time and consideration.

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

That is an interesting idea. I've never seen that before.
Perhaps we are over familiar with hex!
My guess is that it would be very dependant upon the application. Usually I'm quite OK with hex, and then the nibbles become clear anyway. I have used the binary notation when I wish to emphasise a point in code, but rarely otherwise.
Like you say, easy to implement. Good thought.

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

Maybe something like this could do?

#define B8(A,B) (A##B)

ldi r16, B8(0b1001, 1001)

It would be a little cleaner if the preprocessor would allow the "0b" prefix in the define. Anyone know if thats possible?

Mike H.

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

I wonder if there is some other character that the compiler would ignore like:

LDI R16,0b0000.0000

-or-

ANDI R16,0b0000-0000

I'll have to give those a try.

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

For the '.' it'll complain about a float
For the '-' it'll do the subtraction you have asked it to do

In fact almost every "punctuation symbol" has some meaning to the assembler as a form of logical/mathematical operator so I don't think you'll find a benign separator character.

Cliff

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

Hmm, that's too bad 'cause it would be nice to work with strictly binary numbers sometimes without it being a strain on the eyes...especially in a mcrocontroller where there is a good probability that different bit are associated with entirely different I/O devices.
Perhaps in the next version...

Once I get into the MACRO and other definition commands of ASM2 perhaps I'll be able to create myself a suitable substitute, perhaps some sort of nybble substitution(?)

And although it's not supported at the hardware level I think a compiler conversion from

    ADDi W,2        ;Fake Command
    SUBI W,(-2)     ;After Conversion by Compiler

might be a nice ADDITION (no pun intended) Computer Code is should be clear and concise for maintenance purposes, especially Assmebler Code. Substituting SUBI for ADDI reminds me of some of the C "tricks" that programmer use which really should be avoided. One of the reasons I choose to write in assembler is because of the cryptic nature of C. I have trouble following even my own code after only a short period.

It should be easy enough to create a MACRO that would do the required conversion
but I wonder what the response would be when this MACRO command pops-up in code segments.

No only would it allow programmer to follow good coding practice, it would also make the AVR opcode set appear more ORTHAGONAL. Having a SUBI and no ADDI is a head-scratcher for a newbie like me... I thought it was an error in the OPCODE manual.

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

RetroDan wrote:
Here is one useful suggestion that shouldn't be hard to implement:

The compiler I am migrating from allow the use of binary constants as follows:

LDI R16,0b0001_0010 ;Note the great use of the "_" to break the
;byte into two nybbles.


Sorry for late response.

This is a good idea, and will be considered for the next Studio release (issue #4424).

--
roland

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

While we're on the topic of wishlists...
I'd like to see some sort of indication (either a cursor with a different shape, or an indicator in the status bar) when I switch from Insert mode to Typeover mode in the editor.

On my keyboard, the Backspace key and the Insert key are too close together, and I sometimes hit the wrong key by mistake.

- Luke

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

My whishlist.....

I need a more complex conditional assembly directive something like this:

.ifdef ENCRYPT || KEYGEN
	assembly code
.endif

Currently I have to do something like this:

.ifdef ENCRYPT
	assembly code
.else
.ifdef KEYGEN
	assembly code
.endif	; KEYGEN
.endif	; ENCRYPT

This works, but it forces me to make and maintain (i.e. remember to copy it over whenever I change it) two separate copies of the exact same assembly code. If I could use logical operators in the .ifdef or .ifndef directives, then I would only have to maintain one copy of the assembly code.

My boot loader program has exclusive use of SRAM storage while it is running. However, the application code also has exclusive use of SRAM while it is running. I would like some way to reuse the SRAM allocations without getting assembly errors. The defined labels are only used in the Application or Boot Loader section they are defined for.

Application Program:
	.dseg
	.org SRAM_START

	USART_buf:		.byte	128		; application storage

Boot Loader Program:
	.dseg
	.org SRAM_START

	s_box:			.byte	32		; boot loader storage

Even though each example program above is legitimately using SRAM, the AVR assembler will not allow this type of SRAM reuse. This situation forces me to use .equ statements to assign SRAM for the boot loader which is very messy. I suppose I could create a stand alone project just for the boot loader and split up the assembly of the Application and Boot Loader code if I have to. However, my boot loader is the main program entry point to guarantee I can always reflash the application code no matter what. Splitting up the source code would be a big pain.

Maybe there could be a .dseg1 and .dseg2 that would allow assigning labels to SRAM addresses without any cross checking for duplicate address allocation between the two different data segments, or something like that?

For readability, it would be nice to have a built-in syntax to assign a pointer to one of the 32 general purpose registers. Currently if I want an XH:XL pointer to general purpose register r12 I would do it this way:

	ldi XL, low(0x0C)			; initialize the X pointer to point at register r12
	ldi XH, high(0x0C)
or
	.equ p_r12 = 0x0C			; register r12 pointer value
	ldi XL, low(p_r12)			; initialize the X pointer to point at register r12
	ldi XH, high(p_r12)

It would be clearer if there was a built in function for the general purpose register address like:

	ldi XL, low(*r12)			; initialize the X pointer to point at register r12
	ldi XH, high(*r12))

The exact form "*r12" is not important. It could be "!r12", "=>r12", whatever makes sense. An easier solution that is not as nice would be to include 32 equates like the above example equate in the device include file.

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

Mike B wrote:
I need a more complex conditional assembly directive something like this:

.ifdef ENCRYPT || KEYGEN
	assembly code
.endif

This can be done using the .if defined construct, like this:

.if defined ENCRYPT || defined KEYGEN
	assembly code
.endif

Quote:
My boot loader program has exclusive use of SRAM storage while it is running. However, the application code also has exclusive use of SRAM while it is running. I would like some way to reuse the SRAM allocations without getting assembly errors. The defined labels are only used in the Application or Boot Loader section they are defined for.

Application Program:
	.dseg
	.org SRAM_START

	USART_buf:		.byte	128		; application storage

Boot Loader Program:
	.dseg
	.org SRAM_START

	s_box:			.byte	32		; boot loader storage


This can be done by means of enclosing one of the SRAM definitions in .overlap ... .nooverlap directives, like this:

Application Program:
	.dseg
	.org SRAM_START
.overlap
	USART_buf:		.byte	128		; application storage
.nooverlap

Quote:
For readability, it would be nice to have a built-in syntax to assign a pointer to one of the 32 general purpose registers. Currently if I want an XH:XL pointer to general purpose register r12 I would do it this way:

	ldi XL, low(0x0C)			; initialize the X pointer to point at register r12
	ldi XH, high(0x0C)
or
	.equ p_r12 = 0x0C			; register r12 pointer value
	ldi XL, low(p_r12)			; initialize the X pointer to point at register r12
	ldi XH, high(p_r12)


Accessing the general-purpose registers this way is not something I'd recommend except for devices without SRAM. I don't think this suggestion will be implemented in the assembler. If you want to make it prettier you can define macros for loading a register pair with a value, like this

.macro ldptr
    ldi @0l, low(@1)
    ldi @0h, high(@1)
.endm

and use it like this:

    ldptr x, 12  // 12 meaning r12 which of course also can be defined 

Putting all your macros and definitions in a separate file that you include in your program will make this much cleaner.

--
roland