Atmel AVR assembler
in [ASM]
|
Next: int 10h AX = 4F00h
From: Herbert Kleebauer on 23 Jul 2005 05:54 larwe(a)larwe.com wrote: > > > What makes an assembler a "good assembler"? I think a good assembler > > should allow you to write bug free code in a minimum of time. And > > A good assembler should use the mnemonics and rules specified by the > device manufacturer, where there is such a specification. It should > assemble, with the minimum possible modification, code intended for > other assemblers targeting the same part. Great logic. Let's use a bad design because we then at least are compatible to the other bad designs! Why not use a superior design so you are better than all this compatible bad designs? > An assembler that doesn't follow the device manufacturer's rules is a > very low-level HLL, not an assembler. I think this is a definition of an assembler which we hadn't here in a.l.a till now (and we had many different definitions). So, if the manufacturer decides to change his rules, then all the existing assemblers becomes a low-level HLL and some low-level HLL's (which already used the new rules of the manufacturer) becomes an assembler. A real consistent definition of an assembler.
From: Herbert Kleebauer on 23 Jul 2005 05:53 CBFalconer wrote: > Herbert Kleebauer wrote: > >> Also nice for the one that has to maintain your code, long after > >> you've left. Are you going to write an assembler for every uC or > >> uP come across, redefining it's assembly language every time? > > > > Not every uP I come across, but every uP I have to program in > > assembler and which uses an awful syntax like the Intel x86 or > > the Atmel AVR (I liked the PDP11 or 68k syntax). > > And then every time you want to use some code from outside, or from > the chip manufacturer, you have to laboriously transcribe it into > your 'better' mnemnonics and syntax, without error. Similarly for > the joker out there in either space or time who has to use your > special code. That's the nice thing on assembly programming: you can assembly and disassembly it to convert the source to an different assembler. The AVR simulator has no problem to disassemble and simulate the code generated by my assembler. But it seems even Atmel is aware that they use a crazy syntax because any disassembled instruction gets an comment which explains what this instruction does. I prefer a syntax where you directly see what the instruction does without needing a comment. > I strongly advise letting the manufacturer set the assembly > language. Even small deviations can have evil consequences, as I > have found out in the past. When small deviations can have evil consequences, then most probably small deviations can also have positive consequences. Why not try to start an evolution to the better side?
From: Anton Erasmus on 23 Jul 2005 06:21 On Fri, 22 Jul 2005 22:38:11 +0200, Herbert Kleebauer <klee(a)unibwm.de> wrote: >Jeroen wrote: >> "Herbert Kleebauer" <klee(a)unibwm.de> schreef in bericht > > >> I fail to see what's so unusable about the AVR assembler syntax. Your effort >> resembles 68000 code. Writing a good assembler takes time, are you writing >> it from scratch? I think that's a complete wombat; better invest in learning >> the AVR syntax, which is really not that difficult and not unusual. > >What makes an assembler a "good assembler"? I think a good assembler >should allow you to write bug free code in a minimum of time. And >to do this you don't need a powerful macro system or a high speed >assembler or an integrated development system but you surely need >a well designed instruction syntax. And to write a simple assembler >(without a macro system and which is neither optimized for speed >nor size) isn't a big deal. Yes, you have to spend a few hours to >write the assembler, but this will save you much more time when >you write and debug your assembler programs. > >> Also nice for the one that has to maintain your code, long after you've >> left. Are you going to write an assembler for every uC or uP come across, >> redefining it's assembly language every time? > >Not every uP I come across, but every uP I have to program in >assembler and which uses an awful syntax like the Intel x86 or >the Atmel AVR (I liked the PDP11 or 68k syntax). If you really want to use a different assembler syntax, rather write software that translates your syntax into the manufacturer specified syntax. Keeping all the symbols as symbols and not translating them to numbers. You then can use a standard assembler for the device to generate your executable. Regards Anton Erasmus
From: wolfgang kern on 23 Jul 2005 11:59 <larwe(a)larwe.com> wrote: | > What makes an assembler a "good assembler"? I think a good assembler | > should allow you to write bug free code in a minimum of time. And | A good assembler should use the mnemonics and rules specified by the | device manufacturer, where there is such a specification. It should | assemble, with the minimum possible modification, code intended for | other assemblers targeting the same part. | An assembler that doesn't follow the device manufacturer's rules is a | very low-level HLL, not an assembler. I can't agree, CPU/MC-producers actually don't care about sense-making mnemonics. And like Herbert, I also use 'my very own' syntax to at least try to cover all MC/CPU I ever worked on with one cross-compatible language. Of course, x86-coders are not familiar with Herbert's 68000 styled or my Zilog-styled syntax. Therefore I use it only personal and don't try to make it a public need. But Herbert's conversion is pure logical based, even I use hardware ordered register-numbers and have the size-casts in/at the operands. __ wolfgang
From: Herbert Kleebauer on 23 Jul 2005 12:54
Anton Erasmus wrote: > If you really want to use a different assembler syntax, rather write > software that translates your syntax into the manufacturer specified > syntax. Keeping all the symbols as symbols and not translating them to > numbers. You then can use a standard assembler for the device to > generate your executable. I can't see any advantage in generating an intermediate source file but a big disadvantage: for debugging you need a list file and it doesn't help if you get a list file from the "standard" assembler when you have written the source in a different syntax. But how are AVR programs debugged at all? Are there AVR versions which have support for hardware breakpoints or at least single step interrupts? The only alternative I see at the moment is, to add an assembler directive which automatically inserts a call to a debug routine after each instruction. But this would double the size of the code to debug. |