Atmel AVR assembler

{ restricted to comp.arch.embedded }

On Thu, 21 Jul 2005 19:47:04 +0200, Herbert Kleebauer <klee@unibwm.de>
wrote:

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

Jon

On Thu, 21 Jul 2005 19:47:04 +0200, Herbert Kleebauer <klee@unibwm.de>
wrote:

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

I must then be some kind of a God, because I did the impossible,
according to your sentence above. I have been using AVR syntax for
almost two years now, with no problems. Yes, I may have liked better
other ones, but I had no problem using this one.


>so I decided to write my own assembler.

Ok.

>A very 
>first version can be downloaded from:
>
>ftp://137.193.64.130/pub/assembler/adela.zip
>
>Maybe there are some AVR experts who can give some suggestions
>for an improvement or are even willing to do some testing.

Well, good luck with that.

>
>The used syntax:
>[...]

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.

And vice versa.

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

Seems to me like the perfect solution to the (real or imagined) problem.

Herbert Kleebauer wrote:
> But how are AVR programs debugged at all?

Aside from the typical pin twiddling, etc. in hardware, the AVR 
Assembler has a very good simulator.  With it, you can develop and test 
most of a project without a hardware platform, tweak the inputs in 
bizarre ways, and see the effects on every register bit.

It's not a substitute for testing on the platform, but it gets through 
the early stages and logic issues much faster with excellent visibility.

Richard

<larwe@larwe.com> repied:
 
| > I can't agree,
| > CPU/MC-producers actually don't care about sense-making mnemonics.
| 
| That's probably true but irrelevant. Assembly language is defined by
| the CPU vendor. Anything you do that deviate from the vendor's spec is
| writing a new language.

That's new to me, AT&T/gas/gcc/.. use Intel/AMD recommeded style? 
 
| This is a semantic issue. I can't call the OP's product an assembler
| because although what goes in looks like assembly language, it is not
| in fact assembly language for any known processor.

There are that many ASM-dialects around, that any attempt to create
one more logical syntax count for itself, regardless of portability.   
I'm not familiar with Herbert's way either, but I can see the idea. 

If you like to see a few options of my disassembler:

http://web.utanet.at/schw1285/KESYS/index.htm ,[codesnips],[HEXTUTOR]

__
wolfgang

Rich Webb wrote:
> Herbert Kleebauer <klee@unibwm.de> wrote:
> 
> [snip...snip...]
>>
>> 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?
> 
> While I admire your purity of spirit, please do not ever use your
> "improved" assembler on any project involving another programmer or,
> most especially, on any project that may require life cycle support
> for decades.
> 
> Maintenance programmers have a hard enough time as it is. Being
> introduced to a project that needs "a few small changes" and being told
> that, "Oh by the way, the guy that wrote this 17 years ago made up his
> own assembler directives" is not a happy thought. Have a heart.

What he could do, without raising hackles everywhere, is write a
set of macros for m4 to process his version of assembly language
into the generally accepted source.  m4 is generally known, and
available.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In comp.arch.embedded wolfgang kern <nowhere@nevernet.at> wrote:
> <larwe@larwe.com> repied:

> | That's probably true but irrelevant. Assembly language is defined by
> | the CPU vendor. Anything you do that deviate from the vendor's spec is
> | writing a new language.

> That's new to me, AT&T/gas/gcc/.. use Intel/AMD recommeded 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.

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.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> &#4294967295;crivait 
news:3khgbhFucr5sU3@news.dfncis.de:

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

Absurd.

See this:

< http://retroforth.org/asmchart/ >

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.

< http://rosasm.org >

Hans-Bernhard Broeker wrote:

[about assembler syntax]

| > 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.
http://web.utanet.at/schw1285/KESYS/index.htm

Hans-Bernhard Broeker wrote:
> In comp.arch.embedded wolfgang kern <nowhere@nevernet.at> wrote:
>> <larwe@larwe.com> repied:
> 
>>| That's probably true but irrelevant. Assembly language is defined
>>| by the CPU vendor. Anything you do that deviate from the vendor's
>>| spec is writing a new language.
> 
>> That's new to me, AT&T/gas/gcc/.. use Intel/AMD recommeded 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.
> 
> 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.

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.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!