[ASM]STORE/LOAD macros

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

I might be having brain fade here....

I see STORE/LOAD macros defined for ASM that hide the complexity of locations being in I/O or memory space, but I can't get why there are a pair of macros.

STORE is typically used for the pseudocode equivalent of, say, ADCSRA = r16

LOAD is typically used for the pseudocode equivalent of, say, r16 = ADCSRA

But if we were in C-land, we would just say
ADCSRA = var, or
var = ADCSRA

So why can't a single ASM macro exist(say EQUALS) that just makes the first argument equal the second, e.g. you would be able to do the simple (but useless):

EQUALS r16, ADCSRA
inc r16
EQUALS ADCSRA, r16

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

The macros are used (and C will do the same thing) because some of the registers within the I/O range can be accessed with the shorter IN/OUT opcodes while newer chip will have registers that reside in Ram space (ie above 0x3f) that can only be accessed with LDS/STS.

The macros make it easier as one doesn't need to worry about where the registers are located and the same code can be used for older chips (in most cases) and newer chips.

edit the axample you show will NOT work as the first uses IN or LDS while he second uses OUT or STS.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The difference in C is that the variable and the ADCSRA register are defined in completely different ways so they hide the detail allowing them to be used symmetrically in an assignment. One is a numeric value but the other casts an indirect pointer interpretation onto the address of an SFR.

In the Asm though it doesn't have such an advanced facility in the simplistic macro language and as far as a macro is concerned the parameters are only used in a simple string substitution, there's no concept of "type" so how could the macro know that in:

EQUALS r16, ADCSRA

that it needs to use LDS or IN, yet in:

EQUALS ADCSRA, r16

that it needs to use STS or OUT?

It would somehow need to know the type of "r16" or ADCSRA and inside the macro do something like:

.IF TYPE(@0) == REGISTER
 LDS @0, @1
.ELSE
 STS @0, @1
.ENDIF

but the concept of TYPE() and REGISTER is not available.

Cliff

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

...bur aren't registers in known places in memory so that can be detected by the macro and effectively indicates the TYPE?

The AVR001 macros only test whether the source/destination is in IO or data space depending on whethers it's LOAD or STORE - surely if EQUALS tested the first argument and found it in register space then it's either IN or LDS, and if the first argument is in IO or data space then it's either OUT or STS?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
.MACRO EQUALS 		;Arguments: AssignedTo,ReadFrom
.if @0 < 0x20
	.if	@1>0x3F
		lds	@0, @1
	.else
		in	@0, @1
	.endif
.else
	.if	@1>0x3F
		sts	@0, @1
	.else
		out	@0, @1
	.endif
.endif
.ENDMACRO

(can you have nested .if...endif?)

Last Edited: Tue. Apr 27, 2010 - 10:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

...bur aren't registers in known places in memory so that can be detected by the macro and effectively indicates the TYPE?

But when you:

MACRO r16

what's passed into the macro is "r16" not 0x0016. I guess it might be possible to look for 'r' and then N or NN but what if the user has def'd r16 to be 'temp' and uses:

MACRO temp

How could the macro, presented only with "temp" know that it was even a register, let alone which one it was?

I often describe C as simply being a "grown up macro language". I believe that because it allows the kind of thing you are asking for here to be done. While some assemblers have a more powerful set of directives than Atmel Asm2 (gas does!) it's still quite a challenge to achieve the sort of thing that C just does naturally.

Without starting a C v Asm war (because they both have + and -) why don't you simply use C if you are happier with the syntax it offers?

Cliff

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

...but the AVR001 STORE/LOAD macros don't worry about the name passed in - they just test whether @0 or @1 are in the I/O or data space with a simple '>0x3F'

So if @1 is below 0x0020 can't it be assumed to be a register and thus define what EQUALS needs to do

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

Why not suck it and see then?

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

'cos it doesn't work ;)

The macro parser is happy comparing @x with 0x3f when @x is "ADCSRA", but won't compare @x with anything when @x is "r16" (or any other .equ'd name)

[END]

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

MartinM57 wrote:
...but the AVR001 STORE/LOAD macros don't worry about the name passed in - they just test whether @0 or @1 are in the I/O or data space with a simple '>0x3F'
So if @1 is below 0x0020 can't it be assumed to be a register and thus define what EQUALS needs to do
First look in an AVR data sheet register summary section. The addresses start with 0x00 (0x20) to 0x3F (0x5F). The 0x00 to 0x3F are the IN/OUT addresses. The 0x20 to 0x5F are the normal SRAM addresses used with instructions other than IN/OUT. In fact IN/OUT are special opcodes with special addressing range exceptions. The simple '>0x3F' only works because AVRStudio choose to define SREG equal to 0x3F in the assembler include library files. It is equally valid to define SREG as 0x5F and use LDS/STS instead. LDS/STS each take an additional CPU cycle to execute than IN/OUT takes (this is the only reason IN/OUT exist at all).

You are confusing 0x3F as a magic unique identity for IN/OUT use. In fact 0x1F (0x3F) is a different register, yet it can use the 0x3F address with LDS/STS to access the 0x1F IN/OUT register address. In the AVR architecture 0x3F is not a magic identity for unique IN/OUT only address. In fact LDS/STS 0x3F is general purpose register R31. It is just the AVRStudio assembly defines ignore the universal LDS/STS addresses in favor of the special IN/OUT addresses in their specifically setup include file equates. This dual addressing meaning is why the LOAD/STORE macros with their special include file definitions save people from so much grief when writing assembly.

If you want C to be the complexity hiding do allot of work for you with a simple source code statement language, you cannot also expect C to un-hide unique AVR architectural complexity. This is a contradiction that would produce a muddled confusing C language. As Cliff pointed out C does deal with this AVR complexity and causes IN/OUT to be used with its defined register addresses, as usual in a hidden manner. Just like assembly, there is no magic 0x3F address, there is only a contrived AVR special usage convention in both C and assembly, but don't expect these to work the same way in both languages.

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

OK - I see the fundamental error in my ways that no-one really picked up early on...I assumed (didn't look) that r0-r31 were in memory space 0x00-0x1F, but they're in the CPU of course :(

I'm quite happy with LOAD and STORE and programming in ASM, I just had this idea that even the LOAD/STORE complexity could be simplified..

It's beyond my ability, for some reason, to learn C. I have a n,000-line ASM application under continuous development that I would probably love to have in C but there's no way I could convert it (or indeed, have the appetite to)....C is a trick I think I'll leave to my next life

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

Quote:
the LOAD/STORE complexity could be simplified..
What complexity? :wink: They are natural assembly like macro names, you know the direction of the data flow.
Quote:
It's beyond my ability, for some reason, to learn C.
Take heart, you are not alone. Just as it is beyond my ability to do complex maths, do brain surgery (well I CAN do brain surgery, the patient won't be happy though) etc.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

...natural assembly...

Now, THAT is an oxymoron if I've ever heard one. :twisted:

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.