Atmel AVR assembler - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Atmel AVR assembler
timestamped Sat, 23 Jul 2005 18:54:16 +0200:

"[..]

[..] Are there AVR versions
which have support for hardware breakpoints[..]? [..]"

Yes.

Re: Atmel AVR assembler

Quoted text here. Click to load it

Most platforms have rather good C compilers, which is mostly much more
efficient in terms of development time and often more than good enough in
terms of execution time. When I started ARM programming, I didn't have to
care about Assembler syntax at all. Of course, Assembler parts can be linked
in where needed, but these parts are mostly small compared to the size of
the whole system.

I don't think writing a complete new assembler for a given platform being
incompatible to the vendor standards makes sense. Using C saves more time
and costs.

My AVR projects are all >95% C code.

Mit freundlichen Grüßen

Frank-Christian Krügel

Re: Atmel AVR assembler
   I'm quoting a quote because I don't see the original:


Quoted text here. Click to load it

   I don't consider myself an AVR expert, but I might take a look at
it. No one else has bother to comment on your actual assembler.
   I can actually see why you would want to do this, there's an
addressing mode of the AVR's mov that sure seems backwards compare to
how I've seen mov used elsewhere, and I was somewhat bothered by it.
My solution was my mindset: I'm programing the AVR, the processor with
a backwards mov.
   But actually writing an assembler seems extreme to me, especially
when many macro assemblers are versatile enough you can just write new
macros for your new opcodes and addressing modes that expand into the
'standard' assembly code. Have you considered doing this?
   As for the same processor having different assembly mnemonics and
syntax, the most obvious case I recall is the Intel 8080 and Zilog
Z80, both executing the same instruction set (ignoring the Z80's extra
instructions) but with two strongly differring assembly languages.
IIRC, Zilog created the new assembly mnemonics because Intel had its
mnemonics copyrighted.
   Having said that, I have to agree whoever else said it that the C
compilers thesedays have pretty much made this sort of thing moot for
any 8-bit or larger processor. Writing assembly code is less and less
common even for absolute (pun intended) 'bare metal' programming, as
the compilers do quite well with making optimized code. Even so, I
sometimes catch myself looking 'under the hood' to double-check the
compiler, to see just how good the stuff is it's putting out. It's my
decades of having written a significant amount of assembly myself that
makes me do it...

-----
http://www.mindspring.com/~benbradley

Re: Atmel AVR assembler

Quoted text here. Click to load it

:)

A man who builds guitars cannot be completely bad, but
i see no Asm thingie, there. Are you one more of these
guy with a big mouth, about Assembly, without anything
to show?

Not even a small real life Application, with Sources,
to show, after _decades_ of activities?

:)

Betov.

< http://rosasm.org


Re: Atmel AVR assembler


Quoted text here. Click to load it

See point (4) below.

Quoted text here. Click to load it

See point (4) below.

Cheers,
Randy Hyde


There's no need to respond point-by-point to any Rene ("Betov")
Tournois
post. His posts are all repetitive, saying the same nonsense over and
over
again. Therefore, we'll just use "canned" responses to answer his
nonsense.


Here's the key to use:


(1) Rene's continued personal attacks on people and name-calling,
(2) Rene's continued attacks on products,
(3) Rene making unsubstantiated (and ridiculous) claims about RosAsm.
(4) Rene making ridiculous statements about other products, of which he
has no knowledge.


Re: Atmel AVR assembler
Quoted text here. Click to load it

  You are right that the AVR Assembler is not one of the
better industry examples, but you should look to fix only
what is broken.

  Suggestions:

a) You could create a pre-processor, that outputs std AVR_ASM
and includes your codes and comments - that way, you can
still read LIST files, and avoid a whole truck load of work
with symbol/link object files/AVR Core variants.
Use a file extension other than ASM for the starting source.

b) Make the .b suffix default, otherwise that's a lot of dead typing,
and visual clutter.

c) Check carefully that you ARE making code clearer: using a
move for Push/Pop is not widespread, nor is move to alias IN/OUT
on processors that use IN/OUT address space.

  move.b     +(sp),rj            ; j=0..31                    POP
  move.b     rj,(sp)-            ; j=0..31                    PUSH

  move.b     ?adr6,rj            ; adr6=0..63 j=0..31         IN
  move.b     ri,?adr6            ; adr6=0..63 i=0..31         OUT

d) If you really want to move AVR Assembler forward, look at expanding
Randall Hyde's High Level Assembler, to include the AVR :)

http://webster.cs.ucr.edu/AsmTools/HLA/index.html
&
http://webster.cs.ucr.edu/AsmTools/HLA/hla2/0_hla2.html

-jg


Re: Atmel AVR assembler
Quoted text here. Click to load it




If you use an assembler at a regular basis, the used syntax doesn't
matter at all, you just get used to it. For such people maybe the
Atmel syntax is perfect. But if you only seldom write an AVR assembler
program (or even just once in your live in a student project),
then I think, the Atmel syntax is not very well suited. To add a
.b to the instruction costs you two extra keystrokes, but you
write the line only once but maybe read it many times. So, if
the extra ".b" makes it just a little bit better readable, it's
worth the extra typing.

Maybe it's just me, but I think a

                   move.b  r2,r12
                   move.w  r3|r2 , r13|r12

is easier to understand (for somebody who doesn't use the
assembler on a regular basis) than a

  AVRASM ver. 1.77.3 x.asm Mon Jul 25 09:42:19 2005

  000000 2cc2      MOV   R12,R2
  000001 0161      MOVW  R12,R2

even if you need to type a few more characters.

 
Quoted text here. Click to load it

Isn't a pre decrement mostly used for a push? AVR uses a post
decrement. So a
 
    move.b     rj,(sp)-

is much more informative than a simple  PUSH.


IN/OUT instructions are used in assemblers for processors which
have IO instructions (like the x86). The AVR doesn't have IO
instructions but uses memory mapped IO (at least the ATmega32,
haven't read any other manual) at address $20-$5f. Even the registers
are memory mapped (at address $00-$1f). So all we have is a

  mov adr1, adr2

where at least one address has to be <$20. There are short
opcode forms for this mov instruction if the other address
is below $60. Let's assume adr1=$10, then Atmel calls the
move a:

MOV  if adr2<$20  (register register move)
IN   if $20<=adr2<$60
LDS  if $60<=adr2

There is no need to use three different names for a move
instruction depending on the address range. By using
the IN/OUT instructions they also made an address
space shift (to start IO addresses at zero) so we
now have two different address for IO registers. Because
mostly the IO address is given in the IO address space
and not in the memory address space I also had to add
an IO addressing mode:
 
    move.b     ?adr,rj

where ?adr is nothing but adr+$20.

If the assembly language would be well designed, we neither
had registers (r0-r31) nor an IO address space. A simple
"move adr1,adr2" would be sufficient. Depending on the
given address, the the assembler would generate the
correct opcode.

But from a marketing point of view it is much better to
say, AVR has 32 registers and a separate IO address space
than say it correctly:

AVR doesn't have any registers and we have to use a part
of the memory address space for addressing the IO registers
and all the ALU operations like add, and, or, ... are
restricted to the first 32 memory locations (or if immediate
operands are used to the memmory locatioons 16-31). The sad
thing is, that because of this marketing trick we have to use
a bad assembler syntax.
 

Quoted text here. Click to load it

I will not comment this. We have this discussion on
a daily basis in alt.lang.asm and better don't start it in
c.a.e (it will never stop). But it is really a sad thing, that
even people in c.a.e call HLA an assembler.

Re: Atmel AVR assembler
Quoted text here. Click to load it

  My suggestion was to allow .b as implicit. Good tools guide the
user, they do not provide a straight-jacket.
  Doing that allows someone to use .b/.w, if they feel that makes
clearer code [eg heavily mixed Byte/Word code], and also to infer .b if
they prefer [eg many pages of byte-only code]


Quoted text here. Click to load it

  Yes and no. It may tell you that post decr is used, but does
a user need to know that every single time they want to PUSH ?
  With your form, you now have to trap and error message on all
novice forms -
  move.b rj,-(sp),  move.b rj,(sp) etc


Quoted text here. Click to load it

  You have not mentioned a linker, so I presume your assembler does
not support a linker ?
  I'm not sure what you propose could work if the Adr is EXTERN, and of
unknown displacement.
  You also buy into a heap of late error messages, that the linker must
generate, on all physically illegal combinations of adr1,adr2 ?
- ie the devil is in the details....


Quoted text here. Click to load it

  I simply used the description Randall does.

-jg


Re: Atmel AVR assembler
@clear.net.nz:

Quoted text here. Click to load it

If you'd like to discredit yourself to death,
this is a good path to take.

:)))))

Betov.

< http://rosasm.org



Re: Atmel AVR assembler
I've followed this discussion with great interest and I've asked myself
quite a few times what on earth it is you don't like about the AVR syntax.

I have been programming 8085, Z80, 6502, ADSP21xx, Mot's DSP56k, PIC and
8051. When I first started with the AVR, it felt a bit like coming home
again because mayn years ago I did a lot on the Z80.

I think the AVR syntax is good and logical and if you take the time to just
fully pronounce the words the mnemonic stand for, every single mnemonic
becomes a very logical one.

Quoted text here. Click to load it

This is a weird statement. If you program the AVR only seldom, why on earth
bother to write your own assembler? One afternoon with the datasheet at hand
and you're up and running with the AVR!

Quoted text here. Click to load it

?? My first thought was: what are the OR operators doing there?

Quoted text here. Click to load it

To me, a movw is immediately clear to me, as well as the fact that on a
little-endian CPU R13 could be the high order companion of R12. Again
especially if you once have read the datasheet and found the X,Y and Z
pairs....

Quoted text here. Click to load it

As long as I don't manipulate the stack directly, why would I want to know
if a PUSH is pre or post increment?


Quoted text here. Click to load it

Mmmm.... when I see IN in a piece of code, I immediately know that a port or
a peripheral is read. A convenient distinction from a memory location.

Quoted text here. Click to load it

That is your point of view. To me the AVR does have registers and
coincidentally they are part of a larger group of 'registers' that are
adressable with a numerical address instead of a name.

To me this whole discussion has quite a high "much ado about nothing"
contents. Just learn the syntax and start being productive, I'd say.

Meindert



Re: Atmel AVR assembler


Quoted text here. Click to load it

You have to understand, Herbert grew up on the 68K (or similar) and
can't handle an assembly language syntax that isn't 68K-ish. He's
written an x86 assembler using a similar syntax to what he is proposing
here. Every time he posts code to an assembly newsgroup using his
assembler, the response is exactly what people are warning him about in
this thread: "What is this stuff?" No one can read it, no one is very
interested in reading it.

It's probably great for people who learned the 68K (or PDP/11 or Vax)
and can't deal with any other assembler syntax, but it's a mess when
you've got to share code with other people.

Quoted text here. Click to load it

Amen!
I happen to know that Herbert has already written a 68K-ish assembler
for the x86. But even tweaking that is far more work than just going
with the AVR syntax. Unless he's planning on writing 100s of thousands
of lines of code, I, too, fail to see the benefit.

Quoted text here. Click to load it

Me too :-)

Quoted text here. Click to load it

And I still don't believe the former to be more readable.

Quoted text here. Click to load it

And even if you do, what's wrong with PUSH? "PUSH" describes exactly
what is going on at an appropriate level of abstraction. The move
instruction above does not. Heck, why not just write it out as

    move.b rj, [sp]
    sub    1, sp

and let the assembler combine this into one instruction? Then we're
being *real* specific about what's going on here.

Bottom line is that "push" is the right level of abstraction. Any lower
than that and you may as well be specifying hex opcodes.

Quoted text here. Click to load it

I'd say that too, but I've also heard Herbert tell beginning
programmers that the best way for them to learn assembly programming is
to build their own assembler. So I suspect that the problem here is
that he doesn't know AVR assembly and he's following his own advice.
More power to him if he really thinks that's the right way to learn
assembly language programming on a new CPU. I just hope I don't have to
read his code down the road :-)
Cheers,
Randy Hyde


Re: Atmel AVR assembler


Quoted text here. Click to load it

Don't even get into efficiency of keystrokes here!
Unless you're planning to write a *lot* of AVR assembly code, the
amount of work it will take for you to write your *assembler* will
cover a heck of a lot of extra keystrokes in your AVR code. And the
amount of time you spend writing your own assembler can be put to use
reading the AVR syntax that's just a little bit harder to read than
what you're proposing. And the amount of time you spend writing your
assembler is *far* greater than the time it will take to learn and
master the standard AVR syntax.

Yes, I know you already have an x86 assembler that uses a similar
syntax and you could scuttle it to make your AVR assembler. The
argument still stands -- unless you plan on writing a *lot* of AVR
code, it just isn't worth it.

Quoted text here. Click to load it

To you, perhaps, because you already wrote an x86 assembler that uses
the former syntax.

Now it's *your* life so you're welcome to spend the time creating any
syntax you want for an AVR assembler, and I encourage you to do what
*you* want to do; but by virtue of your post you're asking if people
around here think it's a good idea and overwhelmingly, the vote is
"no"! Ever noticed that when you post your x86/faux-68K code that
people get confused reading it? (Indeed, I remember the first time *I*
saw it, I thought it was 68K code.) You make a big point about claiming
that the syntax is just for you, but then you post your code to a
public newsgroup and people just don't follow what you're doing. As
someone else in this thread has pointed out, seeing this type of
"personal syntax" is dreadful when they're asked to support the code
later in life (or simply comment on it when posted to a newsgroup).

As someone who has a *little* experience creating an assembler with a
non-standard syntax :-), I can tell you without hesitation that writing
the assembler is the *easy* part. In order to make the thing practical,
you have to write documentation, tutorials, tons of sample code, and
other tools that support the assembler's syntax. That's a *lot* of
effort to expend just because you don't like the syntax the
manufacturer chose for their assembly language. And to avoid all this
work makes your scheme far worse than the manufacturer's -- as bad as
their syntax may be, at least people can consult a manual and figure
things out.  Herbert-- you're coonstantly claiming "anyone can learn
assembly language by just reading the manufacturer's manuals." How is
someone going to be able to figure out what you've done if they read
the manufacturer's manuals and the syntax is completely different?



Quoted text here. Click to load it

Only to a 68K (or PDP-11/Vax) programmer. Granted, a *few* variants of
the 68K still exist today, but by and large those assembly languages
are dead or dying off. That means it's less likely someone will know
what the syntax above means.

Yes, I understand you loved the 68K. It shows in the x86 assembler you
wrote where you pulled this same sort of stuff. But whenever someone
reads your code (if they can), they have to slowly go over each
instruction, figure out what it does, and map it to the "real" x86
instruction set. This means it takes 5-10x longer for someone to read
your syntax than it does to read Intel's syntax. I'd argue the same
would be true for an AVR assembler you'd write.

Again, feel free to do this, just don't expect people to think it's
easier to read or that the syntax is a whole lot better. Particularly
if you don't supply the documentation, tutorials, support tools, etc.,
that would be needed to make such an assembler accessible to most
people.

Quoted text here. Click to load it

Well, outside of yourself, Rene, and a few others, most people *do*
call HLA an assembler. Learn to deal with it.
Cheers,
Randy Hyde


Re: Atmel AVR assembler
snipped-for-privacy@earthlink.net écrivait news:1122321505.586953.82790
@g49g2000cwa.googlegroups.com:

Quoted text here. Click to load it

Very funny paragraph, once we know that the individual
who wrote the above, is also the one who developed the
most absurd and awfull Syntax every seen, for x86.

Of course, "it's Master Pdf life", even though nobody
ever "encouraged him to do that", and if he succuded
to make an impressive complete unanimity of all the
Assembly Programmers whose "vote was 100% "no"!".

:)))))

Betov.

< http://rosasm.org




Re: Atmel AVR assembler


Quoted text here. Click to load it

See point (2) below.

Quoted text here. Click to load it

Yep, as per my comments, *I* provided documentation, tutorials, and
support tools.

Quoted text here. Click to load it

See point (4) below.

Cheers,
Randy Hyde


There's no need to respond point-by-point to any Rene ("Betov")
Tournois
post. His posts are all repetitive, saying the same nonsense over and
over
again. Therefore, we'll just use "canned" responses to answer his
nonsense.
Here's the key to use:


(1) Rene's continued personal attacks on people and name-calling,
(2) Rene's continued attacks on products,
(3) Rene making unsubstantiated (and ridiculous) claims about RosAsm.
(4) Rene making ridiculous statements about other products or
situations, of which he has no knowledge.


Re: Atmel AVR assembler
timestamped Mon, 25 Jul 2005 10:59:43 +0200:

"[..]

If the assembly language would be well designed, we neither
had registers (r0-r31) nor an IO address space. A simple
"move adr1,adr2" would be sufficient. Depending on the
given address, the the assembler would generate the
correct opcode.

But from a marketing point of view it is much better to
say, AVR has 32 registers and a separate IO address space
than say it correctly:

AVR doesn't have any registers and we have to use a part
of the memory address space for addressing the IO registers
and all the ALU operations like add, and, or, ... are
restricted to the first 32 memory locations (or if immediate
operands are used to the memmory locatioons 16-31). The sad
thing is, that because of this marketing trick we have to use
a bad assembler syntax.

[..]"

AVRs do have registers. Performing arithmetic on values stored only
in registers is quicker than performing arithmetic on values needed
from RAM or ROM.

Re: Atmel AVR assembler
 
Quoted text here. Click to load it

 
Quoted text here. Click to load it

It is only an implementation detail whether the so called "registers"
are implemented as FlipFlops or as the first part of the onchip SRAM.
The AVR architecture doesn't have registers (an architecture is
independent of the actual implementation and an assembler is architecture
specific but not implementation specific). The AVR "registers" are memory
mapped as is the IO.

Re: Atmel AVR assembler
Quoted text here. Click to load it


The registers are imaged in low memory addresses,
but there is an important difference: most operations
can use registers only. The plain memory locations can
be used with loads and stores only.

Please check again a good reference book on
RISC computer architectures.

--

Tauno Voipio
tauno voipio (at) iki fi


Re: Atmel AVR assembler
Quoted text here. Click to load it

 
Quoted text here. Click to load it


   But from a marketing point of view it is much better to
   say, AVR has 32 registers and a separate IO address space
   than say it correctly:

   AVR doesn't have any registers and we have to use a part
   of the memory address space for addressing the IO registers
   and all the ALU operations like add, and, or, ... are
   restricted to the first 32 memory locations (or if immediate
   operands are used to the memory locations 16-31). The sad
   thing is, that because of this marketing trick we have to use
   a bad assembler syntax.

The AVR architecture allows an implementation with separate
registers but can also implemented as a register less CPU with
ALU operations restricted to the first 32 memory locations.
I wouldn't be surprised if there are low cost versions (with
a lower clock speed) which don't have hardware registers. But
as I said, this are implementation details, the AVR architecture
uses memory mapped "registers" and therefore no registers (and
no IO instructions) are necessary in an AVR assembler.
 
Quoted text here. Click to load it

The fundamental characteristic of a RISC architecture is,
that only load/store instruction can access memory. In the
AVR architecture all ALU operation are performed on the
first 32 memory locations. Therefore I wouldn't call the AVR
architecture a RISC architecture. It is a register less
architecture with a short addressing mode for the zero
page.

Which RISC processors do you know, which have a memory
mapped register set?

Re: Atmel AVR assembler
Quoted text here. Click to load it

Registers are logically just fast memory with a short form
of addressing and predefined "names".  There are usually
arithmetic and logical operations that can be performed
on registers that can't be performed (directly) on other
locations.  The AVR happens to map the "registers" to
memory locations (as a number of other processors have
done over the years).

Re: Atmel AVR assembler
Quoted text here. Click to load it

The registers are in the register file which is
a small RAM.

The separate I/O address apage is just marketer's fog
into the customer's eyes.

In the same way, there are multiple names for
the same basic instructions. It took some time
for me to decode.

The processor architecture is better than the desription.

Quoted text here. Click to load it

The registers have only memory mapped *images*. All
the normal register operations are performed with
register addressing.

When all the RAM is internal to the processor chip,
it's bloody difficult to tell which amount of
register array is just a register bank and which
amount is then memory used as registers.

If the registers were regarded as a special zero page
(without the traditional zero-page uses a la PDP-8),
the instruction set would be described as a mess.

The main effect of memory-mapping the registers
and I/O is loss of some of the memory addressing
capability.

To me, it's a pretty traditional RISC (without delay
slot problems) and extra possibility to index into
the register bank.

----

The asssembly code is different from e.g. PDP-11 or
Motorola 68xx and 68xxx, but it does not make it
worse. There are selections done which seem to
annoy you, but still there is no sense to fight
it and claim that the other way is better.

--

Tauno Voipio
tauno voipio (at) iki fi


Site Timeline