Atmel AVR assembler

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

Reply to
Jonathan Kirwan
Loading thread data ...

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.

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!

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

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

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

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.

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

Reply to
Meindert Sprang

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.

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?

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.

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

Reply to
randyhyde

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.

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.

Me too :-)

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

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.

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

Reply to
randyhyde

I've written ten of thousands of lines of 68K assembler in my time. I think it's a very easy to use instruction set format.

I've also written Z80, 6509, 6809, ARM, PIC, 8501, 80x86 and PowerPC. They all have unique qualities and assembly format.

I can see the appeal of wanting a prettier assembly language for AVR than the standard one. I think it's great that you've taken it on, and if you enjoy working with it then that's marvellous.

But if this is for a work project, don't use it. Use the standard syntax. Regardless of your sense of aesthetics, you would be a POOR ENGINEER if you impose a non-standard language on your company. Sooner or later someone may have to support your work and you would be creating a barrier for them.

It's simply not your place to declare, in a professional environment, that the standard used by all AVR programmers is "unclean" and unilaterally implement something else.

For your own personal hobby, it's great - do whatever is easier for you. Be happy. Share you work, as you're doing.

For work, you're being paid as a professional engineer. Behave like one.

Regards, Paul.

Reply to
Paul Marciano

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

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.

<
formatting link
>
Reply to
Betov

If I recall correctly, many many years ago, there was an effort by the IEEE towards a ®standard¯ framework for assembly languages. What happened to this effort?

Despite the particular instruction sets of various processors, there is a lot of similar things that assemblers have to express: comments, constants, data declaration and definitions, macros, types of memory, etc.

Whatever the processors, there are similarities between instructions: all processors copy data from one place to another, they execute arithmetic instructions; so why not have the same mnemonic for the same instruction.

One of the first assembly languages that I learned was that of the IBM's System/360. It is not perfect but it has interesting features like LD (load) to denote a copy from a memory location to a register, and ST (store)to denote the reverse operation. A suffix to the instruction denotes not only the length of the operand but also its nature: STE means copy from a memory location to a floating-point register.

It is much easier to learn than the Intel x86 family assembler where the mnemonic MOV is used and where one has to look at the declaration of an operand to assess its size.

--
Jean Castonguay
lectrocommande Pascal
Reply to
Jean Castonguay

See point (2) below.

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

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.

Reply to
randyhyde

See point (4) below.

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.

Reply to
randyhyde

The Intel x86 assembly language syntax was designed to provide additional semantic information to the assembler in order to help it catch programming errors that would otherwise slip past. I think I could agree with your assessment that the Intel syntax is more difficult to learn, but that expense has a benefit -- it helps catch errors that would otherwise slip past the assembler.

I've used lots of assemblers (i.e., most non-Intel assemblers) where the assembler doesn't bother checking things like operand sizes (indeed, the assembler has no concept of "variable size" in memory). Once I got used to the "overhead" of the Intel syntax, I came to appreciate the fact that it does catch a lot of stupid mistakes that would otherwise slip through the cracks.

Given how rarely one should be coercing a memory object to some other size (other than its declared size), I can live with " PTR" in those rare instances when you really do need to coerce a memory object to some other size. And given the presence of TEXT equates and functional macros in assemblers like MASM, TASM, and HLA, it's easy to create a shorthand symbol when you wind up doing an excessive amount of coercion.

Of course, for those who just *have* to use mnemonics like MOVB, MOVW, and MOVD, you *can* create your own instructions using an assembler that has decent macro facilities. Much easier than writing your own assembler, though the problems of having other people read your code still exist (though, arguably, because the macros are present in the source code they *are* documented). Cheers, Randy Hyde

Reply to
randyhyde

I think you mean L to match ST, or STD to match LD.

LH is 16bit integer load. STH is 16bit integer store.

L is 32bit integer load. ST is 32bit integer store.

LE is a floating point load, short. STE is floating point store, short.

LD is a floating point load, long. STD is floating point store, long.

It's mostly the floating point instruction that have the size suffix, and then it's not always the last character.

Had to consult the green card for the floating point info. :-)

--
ArarghMail507 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
Reply to
ararghmail507NOSPAM

Your posts are generally offensive, and are certainly of no consequence in this particular discussion. I'm not (before you decide to flame me) a user of HLA, nor will I *ever* be a user of RosASM (whether it works or not), as I have seen all I wish to of your flaming, and will not subsidize it.

If you've nothing of substance to contribute to the ongoing debate on what constitutes a "real" implementation of an X86 assembly language tool, I'm sure I am not alone in hoping you will merely observe.

Bill

Reply to
William Meyer

And it would be a much more responsible approach to the issue than running off into left field and inventing an "improved" syntax.

Bill

Reply to
William Meyer

And none of them particularly difficult to learn.

Very well said.

And again. For any commercial work, it's unprofessional to overlook the likelihood that someone other than yourself may have to perform maintenance.

Perfect summation!

Bill

Reply to
William Meyer

Worth a fortune, almost as much as a S/360 Principle of Operations manual. Sure it isn't a later S/370 yellow card? I don't remember the FP stuff on S/360 green cards, but my memory might be failing me.

--
Regards
Alex McDonald
Reply to
Alex McDonald

I have 2 of GX20-1703-8 and 2 of GX20-1850-1.

The FP stuff is on page 3 of the first, and pages 3 & 4 of the second.

The PO's are out in the garage, along with most all of the MVT 21.6 manuals. :-) Also, S/370 PO's. Assuming that they haven't been damaged.

I thought I had more than 2 green cards, but I can't find them just now.

--
ArarghMail507 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
Reply to
ararghmail507NOSPAM

so what have you written? "ten of thousands of lines of 68K assembler" of what? An operative system or other?

Reply to
¬a\/b

William Meyer écrivait news:ZieFe.450$kk6.139 @newssvr13.news.prodigy.com:

If someone can translate this strange sentence in english...

Thanks in advance.

Betov.

<
formatting link
>
Reply to
Betov

Your inability to parse a perfectly clear English sentence is not our responsibility. However, Mr. Meyers hopes have apparently not been met.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

CBFalconer écrivait news: snipped-for-privacy@yahoo.com:

Sorry, but the above sentence members do not make any sense to me:

  • "If you've nothing of substance to contribute"

... targetting... what??!!!... First, my "contribution" is 3 Megas of Assembly Source called "RosAsm". Second, all i did, in this absurd thread, was to point out some lies ans swindlings that can not be ignored.

  • " to contribute to the ongoing debate on what constitutes a "real" implementation of an X86 assembly language tool..."

The Title of this thread is "Atmel AVR Assembler", and i did not post _one_ single message about that suject, that is of no interrest to me.

As for Herbert choices, we have already discussed this, and Herbert knows what i think about his point of view.

  • "... I'm sure I am not alone in hoping you will merely observe".

So, he is sure he is not alone in hoping that i "will merely observe"... what???!!!... Simply means "i wish you could shut up"? If so, this is exactly what i did, as this thread has no interrest to me... until Master jump into the band wagon for selling his usual insanities.

If this "disturbs" somebody, that the last remaining Asmers could still be allowed to post anything, to defend Assembly, on a Assembly News Group, these "somebodies" can go elsewhere, as there are plenty of other places, where our famous swindler can spread his self-selling propaganda, without any opposition.

For all the other silent ones, shame on them, for not helping, each time the swindler writes sentences like this:

- "I know all Assemblers"

- "I am an Assembly teacher"

- "I have written millions of lines"

- "HLA is an Assembler"

- "... TASM, MASM, HLA..."

- ...

... and let the damages caused by that ass-hole go in peace. Shame on the ones who know what Assembly is, and who keep silent, in such cases of aggression.

Betov.

<
formatting link
>
Reply to
Betov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.