Re: Atmel AVR assembler

{ restricted to comp.arch.embedded }

On Thu, 21 Jul 2005 19:47:04 +0200, Herbert Kleebauer <klee@xxxxxxxxx>

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

I've been reading the exchange. My qualifications to comment on your
desire for your own assembler:

(1) I've written my own symbolic assemblers before. Some of them,
because there was no assembler available to me. One or two times,
because I didn't like the available assembly language syntax. So I've
been to a similar place where you are at, I suppose. They are often
fairly simple to write -- I wrote one for the HP 21xx CPU that worked
well in just a weekend, after only a couple years of light programming
experience for personal interest.

(2) In my professional work, I've built development tools of my own
making that were required to create a finished product for my clients.
By this, I mean to point out that my clients were _required_ to use
these one-off tools I built in order to build their final target code.
This is not usually a good circumstance to place a client into,
because there is no support, usually slim documentation, and yet one
more thing that they need to be able to develop and build, with its
own tool requirements on top of everything else. However, there have
been cases where there was no other possibility (in a case I'm
thinking of now, it was with the ADSP-21xx processor and where the
existing tools at the time could not automatically incorporate the
calibration tables for the ROM image we needed for the hardware design
we had at hand -- the "installation" of that calibration table was
handled by my tool.)


Let me point out some thoughts:

(a) Elsewhere, you have both implied and said outright that you
justify redesigning the assembly syntax and developing an assembler on
the idea that doing so will pay off through faster coding or better
resulting code or something along these lines. You assume that this
is true for everyone else, I suppose, because this is how _your_ mind
works. No one can deny your ability to speak for yourself, of course.
But there is no reason to believe you can speak for others on this
score or that the assembly language _you_ design for _your own_ better
way of thinking will necessarily apply to anyone else. It may. It
may not.

(b) Assemblers aren't just stand-alone assemblers. In most cases,
they don't even generate the final binary object. And there may be a
number of separately assembled/compiled modules. The output is then
taken up by a linker or locating linker that itself supports quite a
variety of controllable options, such as segment copying for cases
where initialization constants need to be copied to a ROM/flash
segment for non-volatile storage while most of the code needs to be
linked to the RAM segment locations, for proper operation during
execution. In other words, the assembler does not sit around as an
isolated tool, but rather as one part in an overall system that offers
a great deal of flexibility and power. When you choose to write your
own assembler tool, you may either (b1) choose to throw away those
useful features, or (b2) have to discover how to integrate what you've
written as part of that overall tool chain so as not to void those
features, or (b3) also re-write the rest of the tool chain in order to
capture the desired features.

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


I guess my take on all this boils down to the following:

(I) I don't have any difficulty, these days, with assembler syntax.
I don't feel much need to change it as my experience says that it does
usually not get in my way of thinking about the broader problems. And
it is those problems where I need to focus. The assembly syntax is
merely a detail.

(II) It is very difficult to justify writing an assembler of your
own. It may throw away a great deal of well-burnished knowledge by
the vendor, born of extensive experience on their part. It may also
throw away their other tools as part of the development process,
adding still more things that need to be done well before actual
development can begin. It will certainly add development and
maintenance costs to the client/employer. And the pay off is rather
small, if present at all.

Which brings me back full-circle to your comments suggesting that
there is a worthwhile pay-off. I just don't agree. There is very
little difference to me, at the assembly language level, between
calling an inclusive-or instruction OR or IOR. I'll figure it out
once and then just move on. Nor does it really help me to call a
register R4 or %4, or to put the destination first or second. It
takes a few seconds to get the idea and then I just move on.

Now, all this said, I really like what Randy Hyde did. He didn't just
go around screwing with instruction syntax but instead added
interesting constructs to his assembler tool. Built-in support for
coroutines and thunking was really nifty, for one thing! But then, a
lot of folks might not call it an assembler, anymore.

Perhaps you might consider designing and writing a re-targetable
assembler? One where you could express your algorithms in their
essential, low-level but still abstracted form and let the tool
retarget the code for the particular CPU. It would need to include a
great deal of data flow analysis and automatic register assignment, I
suppose (some CPUs only have only one or two, some many.) It may also
need to handle ALU status bit differences and optimize for various
conditional branch implementations. But then you are reaching right
back up into compiler territory, yes?

Have you looked at Randy Hyde's assembler or at BLISS?

Anyway, while I can write (and have written) assemblers, I don't. I
use the tools that the vendor makes available simply because it is the
right thing to do for my clients or employers.