Atmel AVR assembler

Herbert Kleebauer wrote:
> Have to write some AVR code and therefore have read the 
> AVR Instruction Set manual and tried the assembler included
> in  AVR studio. I think the used syntax is completely
> unusable, so I decided to write my own assembler. A very 
> first version can be downloaded from:
> 
> ftp://137.193.64.130/pub/assembler/adela.zip
> 
> Maybe there are some AVR experts who can give some suggestions
> for an improvement or are even willing to do some testing.

  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

Ben Bradley <ben_nospam_bradley@frontiernet.net> &#4294967295;crivait 
news:va58e1l9h89a21plnjbqkb606v184c3ni5@4ax.com:

> It's my
> decades of having written a significant amount of assembly myself that
> makes me do it...
> 
> -----
> http://www.mindspring.com/~benbradley

:)

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 >

Jim Granville wrote:
> Herbert Kleebauer wrote:

>   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.


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

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.

 
> 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.

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.
 

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

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.

Herbert Kleebauer wrote:
> Jim Granville wrote:
> 
>>Herbert Kleebauer wrote:
> 
> 
>>  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.
> 
> 
> 
>>b) Make the .b suffix default, otherwise that's a lot of dead typing,
>>and visual clutter.
> 
> 
> 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.

  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]


> 
>>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.
> 
> 
> 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.

  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


> 
> 
> 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.

  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....


> 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.
>  
> 
> 
>>d) If you really want to move AVR Assembler forward, look at expanding
>>Randall Hyde's High Level Assembler, to include the AVR :)
> 
> 
> 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.

  I simply used the description Randall does.

-jg

Jim Granville <no.spam@designtools.co.nz> &#4294967295;crivait news:42e4c5e2
@clear.net.nz:

>>>d) If you really want to move AVR Assembler forward, look at expanding
>>>Randall Hyde's High Level Assembler, to include the AVR :)
>> 
>> 
>> 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.
> 
>   I simply used the description Randall does.

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

:)))))

Betov.

< http://rosasm.org >

Jonathan Kirwan <jkirwan@easystreet.com> writes:
> { restricted to comp.arch.embedded }
> Herbert Kleebauer <klee@unibwm.de> wrote:
> 
> >Have to write some AVR code and therefore have read the 
> >AVR Instruction Set manual and tried the assembler included
> >in  AVR studio. I think the used syntax is completely
> >unusable, so I decided to write my own assembler.
[snip]
> Let me point out some thoughts:
[snip]
> (c) Writing your own tools for a client project (or your employer's
> project) means adding yet another project to the body that must be
> preserved by them.  They must have a way of reconstructing the tool
> you write, if needed, and they must have a way of repairing bugs or
> adding other needed features as time proceeds.  Not to mention the
> fact that they may need to rehost the tools.  Anyway, a history of bug
> fixes and added features needs to be tracked; code branches
> maintained; etc.  WHICH MEANS THEY HAVE TO PAY FOR THIS.  But when you
> rely upon the tools of your vendor (and the assembly tool chain,
> including the linker and so on, is very often free and otherwise often
> quite good despite your disagreement at times over the assembly
> syntax), you can capture all the effort that the vendor supplies in
> their tool chain.  And this includes the development changes and
> extensive testing on various machines and operating environments.

This particular point cuts both ways.  If the available
tool(s) is(are) unsupported and have bugs, what do you do?
Even if there aren't any support issues, the tool(s) have
to be retained for future product support.

On Mon, 25 Jul 2005 05:10:34 PST, mojaveg@mojaveg.iwvisp.com (Everett
M. Greene) wrote:

>Jonathan Kirwan <jkirwan@easystreet.com> writes:
>> { restricted to comp.arch.embedded }
>> Herbert Kleebauer <klee@unibwm.de> wrote:
>> 
>> >Have to write some AVR code and therefore have read the 
>> >AVR Instruction Set manual and tried the assembler included
>> >in  AVR studio. I think the used syntax is completely
>> >unusable, so I decided to write my own assembler.
>[snip]
>> Let me point out some thoughts:
>[snip]
>> (c) Writing your own tools for a client project (or your employer's
>> project) means adding yet another project to the body that must be
>> preserved by them.  They must have a way of reconstructing the tool
>> you write, if needed, and they must have a way of repairing bugs or
>> adding other needed features as time proceeds.  Not to mention the
>> fact that they may need to rehost the tools.  Anyway, a history of bug
>> fixes and added features needs to be tracked; code branches
>> maintained; etc.  WHICH MEANS THEY HAVE TO PAY FOR THIS.  But when you
>> rely upon the tools of your vendor (and the assembly tool chain,
>> including the linker and so on, is very often free and otherwise often
>> quite good despite your disagreement at times over the assembly
>> syntax), you can capture all the effort that the vendor supplies in
>> their tool chain.  And this includes the development changes and
>> extensive testing on various machines and operating environments.
>
>This particular point cuts both ways.  If the available
>tool(s) is(are) unsupported and have bugs, what do you do?
>Even if there aren't any support issues, the tool(s) have
>to be retained for future product support.

I try and keep backups of all of the tools used to produce any
project.  This means, for example, keeping the exact version of MPLAB
used on that project, despite the fact that newer versions *may* still
be compatible.  I preserve my old Microsoft compilers and Borland
compilers and Zortech and Lattice C and so on, for exactly the same
reasons.  I have so many of these around now, but I keep them
maintained together with the projects so that I can always go back and
reconstruct the executables.  So your last sentence about retaining
tools for future product support is right on target.  That is a must.

The above issue comes to the fore for me when developing on a tool
where I may not be able to legally restore the compiler toolset.  In
those cases, I try and avoid the tools in the first place.  An example
here happened in the case of tools from Analog Devices, where the
toolset was key-locked to the machine.  What happens to me, say 5 or 8
years later when a client asks me to make a small but important
feature addition?  I set about to recover my tools and source code
and, no longer having that exact machine with the exact same disk
drive, discover that I cannot operate the compiler, at all.  So I call
up Analog Devices for help.  And do you imagine that even they know
how to help me, after so much time has gone by?  Or will keep records
of my ownership that long?  Or still have their own tools by which to
regenerate the unlocking code given information I provide them on my
new system??

I stay away from such situations like the plague.  This is one of the
reasons I do NOT use tools locked to machines.  I am still, today,
supporting tools where the code was developed using Lattice C around
the year 1987.  I still have the complete tool chain used for that
project, including some tools by Intel needed for the locating part of
the linking process.  And because the OBJ files of Lattice C aren't
entirely compatible with those locating linkers from Intel at the
time, I also have a custom tool needed to modify the OBJ file so that
it is acceptable.  I have that tool and the source code and the
development chain for that, too.  The point here is that I need to be
able to support clients I have for periods of 20 years and longer.  So
my concerns about what tools I buy are severe.  (Similarly, I have
working 80286 and 80386 machines I keep around, along with boxes of
multi-I/O cards, floppy and hard disk cards, and so on to maintain
them -- when I find some tools will not run properly on modern PCs.)
So I will only use tools I can rely upon, even when the vendor has
gone out of business entirely and cannot be called upon.  This means
no machine-lock crap, unless the vendor is willing to give me an
unlock code that will work on any machine.  (An owner of Paradigm,
after listening to my needs, very generously gave me a complete
toolset with such a code, for example.)

Regarding 'bugs' or whatnot, I just gave an example above where I
*had* to develop a tool.  The Lattice C compiler did not, at that
time, have the ability to locate code.  However, the system is not PC
compatible and is a dedicated 8088 design -- a truly embedded system.
So I had to use the Intel toolset for the locating feature.  But to
make that work, I needed to build something to mediate between the OBJ
files that Lattice C wrote out and the OBJ files that the Intel tool
could accept.  Sometimes, this happens.  And when it does, you do what
you have to.

But then, it's easy to explain to people why you did.  There is no
real question.

Jon

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.

> 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.

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!

> Maybe it's just me, but I think a
>
>                    move.b  r2,r12
>                    move.w  r3|r2 , r13|r12
>
> is easier to understand

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

> (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

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....

> 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.

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


> 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.

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.

> AVR doesn't have any registers and we have to use a part
> of the memory address space for addressing the IO registers

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

Herbert Kleebauer wrote:
>
> 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.

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.

>
> 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.

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?



> > 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.
>
> 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.

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.

>
>
> > d) If you really want to move AVR Assembler forward, look at expanding
> > Randall Hyde's High Level Assembler, to include the AVR :)
>
> 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.

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

Meindert Sprang wrote:
> 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.

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.

>
> 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.
>
> > 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.
>
> 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!

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.

>
> > Maybe it's just me, but I think a
> >
> >                    move.b  r2,r12
> >                    move.w  r3|r2 , r13|r12
> >
> > is easier to understand
>
> ?? My first thought was: what are the OR operators doing there?

Me too :-)

>
> > (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
>
> 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....

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

>
> > 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.
>
> As long as I don't manipulate the stack directly, why would I want to know
> if a PUSH is pre or post increment?

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.

>
> 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

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