Atmel AVR assembler

Hans-Bernhard Broeker écrivait news: snipped-for-privacy@news.dfncis.de:

Absurd.

See this:

All of the actual Assembler branch from NASM, plus, a little bit of inspiration from TASM (concerning FASM), and from A86 (concerning RosAsm, and maybe, GoAsm).

None of the actual Assemblers Authors would be stupid enough for "striving to emulate" anything like MASM.

Betov.

| > That's new to me, AT&T/gas/gcc/.. use Intel/AMD recommended style? | No. But I'm willing to forgive AT&T (and GNU, which borrowed their | syntax) this violation of a well-founded principle, on the grounds | that Intel's original x86 assembly language is so incredibly horrible.

This AT&T solution is absolutely not well suited for x86 processors, it's weird and confusing and far away from explaining an operation. Just read all the FAQ's on it. | Actually, there are only two real dialects of x86 assembly these days: | MASM (MS's implementation of the original Intel syntax), and gas. All | other assemblers that want a noticeable share of the market strive to | emulate either of these to the letter.

Yes, the market share ... and MASM as the Windoze/C-side tool. But as we last few pure ASM-coders here in A.L.A see and use many things far beyond the M$-world imagination, we aren't bound to it. How will MASM rank within C+/-..?, I think less than one per million.

btw: FASM/NASM seem to be the most used by ASM-newbies recently, you may say this are only a handful, but the ASM-population grows daily.

__ wolfgang kern (Author of KESYS) How fast and short could windoze be if everyone would think like me.

Actually the rationale for gas is even simpler. It is based on the requirements for an assembler for gcc, which at one point required a suitable ordering of operands and means of specifying actual opcodes. It was developed with what amounts to apologies because of those needs, gcc being less capable of adapting than most humans.

Many of the convolutions of MASM can be blamed on the abysmally complex object code format, which was imposed by Intel way back when. As usual Microsoft took that and misapplied it, while adding their own incompatabilities. That object format is now largely forgotten, but the effects are still here.

Intel *did* write their own assembler. It was called ASM86 (and then ASM286, and then ASM386). IIRC, they stopped around the 386 version because DOS had become so ubiquitos as a development platform and MASM was pretty much ASM86 syntax compatible.

Hmmm... Last time I checked, Intel hired some computer scientist types to develop the *assembly language* for the original 8086. Indeed, most of the complaints I hear from people in this newsgroup about Intel's syntax (type checking, addressing semantics, etc.), probably exist because they *had* computer scientists rather than electrical engineers design the syntax :-).

Cheers, Randy Hyde

Last time I counted, there were about a half-dozen different dialects of x86 assembly language. I don't know how you define "real", but assemblers like NASM, FASM, GoAsm, TASM, MASM, Gas/ATT, Gas/Intel, and HLA all have fairly decent followings (numbering in the thousands of users, each). Granted, MASM (because of its 20-year history) has the largest market share, by far, but the others are growing and cutting into that market share. Particularly as people move away from using the Windows platform. Cheers, Randy Hyde

"Randall Hyde" écrivait news:QgOEe.3092$ snipped-for-privacy@newsread3.news.pas.earthlink.net:

• HLA is not an Assembler. It is an HLL Pre-Parser, that reads a Source File in HLA Syntax, and outputs nothing but an Asm Source.

• HLA has almost no users, as everybody can see by taking a quick look at the various boards, where you try to damage Assembly, by selling yourself. HLA has only a couple of _victims_ each week, who are gone one or two weeks later, not considering the tiny couple of definitive idiots keeping stuck with this horror.

:)

Betov.

"wolfgang kern" écrivait news:dc0cfm$76k$1 @newsreader1.utanet.at:

Indead. I regulary take a look at all Assemblers Boards, and the number of Posts, for example, at FASM Board, is now beating the number of MASM Board Posts.

Also, considering that there is, so to say, no real Asmers using MASM (99% of them are HLL Programmers making occasional use of MASM for HLLs' enhancements...), and that most of FASM users are real Asmers doing real things (like the MenuetOS developers, and such...), the real growing rate of the real "ASM-population", is quite encouraging.

:)

Betov.

Don't see the logic of this statement. Just because they once did have an assembler doesn't mean that they still sell an assembler. And if they currently don't have an assembler then they also have no assembler syntax. Even if Intel would again write it's own assembler, they couldn't say, this is the only valid assembler syntax for x86 processors.

They can define the language for an "Intel x86 assembler" but surely not "the" assembly language for the x86. Everybody can define a syntax for a x86 assembler (not only Intel) and they are all equal. If we can't ignore (because of the market power) an awful processor architecture (like Intel X86 or Atmel AVR) then we at least should ignore the even more awful assembler syntax used by this companies.

You want to waste the c.a.e people's time with this? The r.g.i-f people have alread complained about this!

NoDot, ...

"NoDot" écrivait news:1122227437.170347.262770 @g43g2000cwa.googlegroups.com:

Said by one from "the tiny couple of definitive idiots keeping stuck with this horror"...

:))

"c.a.e", "r.g.i-f", "alread", you are sure it was not "comdlainep", kid?

:))))))

Betov.

That's quite obviously not what Randall was trying to make it mean, either.

The fact that Intel actually not only documented an assembly syntax along with the processor pretty much from the get-go, but even implemented it themselves as part of marketing the chip, establishes the fact that there does exist something that doesn't leave us much chance but to call it "the" standard assembly language for this processor: that used and published by Intel. It's quite a broken design of an assembler, granted, and nobody's expected to like it particularly --- but it's still the standard syntax.

This standard assembly language for x86 CPUs is also the root of the entire MASM-compatible family of x86 assembly dialects. The members of that family may not all be compatible with each other (although most can still be switched to actual MASM source compatibility) --- but they're all roughly compatible to ASM86. I.e. you can still feed assembly source from the original 8086 application notes and data sheets (or from books from that era) to MASM or one of its derivatives (running in compatibility mode, where necessary) essentially unchanged, and expect it to work. Even "rogue" assemblers like a86 still accept that assembly language, even if they'll grumble a lot about it.

The only truly independent assembly language family for x86 that I'm personally aware of is AT&T (including its GNU descendants). Off-hand, this fundamentally incompatible language looks like a very bad idea, so it needs to be abandoned or justified.

I think AT&T x86 assembler language makes a whole lot more sense than Intel's ever did. Not because of the oft-maligned opposite order of source and destination operand, mind you, but because it puts the definition of operation width where it belongs (as a letter in the opcode) instead of where it has to be second-guessed (by inspecting stuff like BYTE PTR [whatever]). The price to be paid for this improvement of the syntax was a loss of direct access to the entire body of pre-existing assembly source. AT&T deemed that acceptible, probably because they didn't plan on using their 'as' on any third-party original assembler sources anyway, and the compiler doesn't care what language it emits.

The main problem with Intel syntax IMHO is that they were trying to let the assembler do half the linker's and a good part of the human's job on top of that of a genuine assembler. Frankly, if the human programmer has to look at more than one line of source code (setting aside macros) to figure out which actual opcode a given line of assembly code will generate, something's seriously wrong with that assembler. Once they had added BYTE PTR [] and ASSUME to the language, the damage was irreversible.

AVR Studio has a Simulator - which uses the official AVR syntax of course. :-)

Bigger parts have a JTAG port for use with the Atmel JTAG ICE (both the older and the new MKii version), where you can single-step, view and change cpu and peripheral registers etc. Works with AVR Studio.

Newer smaller parts have debugWire, a debug port using a single pin (reset). This requires the Atmel JTAG ICE MKii and AVR Studio.

Atmel also sells real In-Circuit Emulators - to be used with AVR Studio.

It's everything there, and everything works fine - and requires the AVR Studio and proper symbol tables generated by the compiler, assembler and linker.

Mit freundlichen Grüßen

Frank-Christian Krügel

I'm quoting a quote because I don't see the original:

On Fri, 22 Jul 2005 17:55:32 +0200, "Jeroen" wrote:

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

-----

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

-jg

Ben Bradley écrivait news: snipped-for-privacy@4ax.com:

:)

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.

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

even if you need to type a few more characters.

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 d) If you really want to move AVR Assembler forward, look at expanding

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.

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]

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

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

I simply used the description Randall does.

-jg

Jim Granville écrivait news:42e4c5e2 @clear.net.nz:

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

:)))))

Betov.

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.