Atmel AVR assembler
in [ASM]
|
Next: int 10h AX = 4F00h
From: Jim Granville on 25 Jul 2005 06:58 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
From: Betov on 25 Jul 2005 07:25 Jim Granville <no.spam(a)designtools.co.nz> ý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 >
From: Meindert Sprang on 25 Jul 2005 15:21 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
From: randyhyde on 25 Jul 2005 15:58 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
From: randyhyde on 25 Jul 2005 16:12
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 |