Atmel AVR assembler - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Atmel AVR assembler
Quoted text here. Click to load it
[snip]
Quoted text here. Click to load it
[snip]
Quoted text here. Click to load it

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.

Re: Atmel AVR assembler
On Mon, 25 Jul 2005 05:10:34 PST, snipped-for-privacy@mojaveg.iwvisp.com (Everett

Quoted text here. Click to load it

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

Re: Atmel AVR assembler

"[..]

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 from what happened to the European Space Agency, whether Analog Devices
would continue to provide contractually required support itself.

Re: Atmel AVR assembler
Quoted text here. Click to load it

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.


Re: Atmel AVR assembler
Quoted text here. Click to load it

And none of them particularly difficult to learn.

Quoted text here. Click to load it

Very well said.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Perfect summation!

Bill

Re: Atmel AVR assembler
Quoted text here. Click to load it

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

Quoted text here. Click to load it


Re: Atmel AVR assembler

Quoted text here. Click to load it

Hey, thanks for the interest.  I grew up on home computers - my first
exposure to the 68K was the Atari ST, on which I wrote non-commercial
games.  No money for a C compiler so it was all in assembly.  Over the
course of a few years that was easily my first 10,000 lines of code for
graphics, sprite engines, interrupt-based screen effects, sound
programming, low level access to the floppy disk controller, DMA, and
of course higher level game logic.

Professionally I worked on VME based networking devices, mostly in 'C'
but also boot code, exception handlers, crash dumps.  Worked at that
level on a number of projects.

Tens of thousands of lines over the course of 8 or 9 years.

Big fun.  Even though I almost exclusively work in 'C' above the
operating system nowadays, I never pass up an opportunity to get down
and dirty with microcontrollers or assembly language.  Yes, I'm a geek.

Cheers,
Paul.


Re: Atmel AVR assembler OT:IEEE standard assembly language
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


Re: Atmel AVR assembler OT:IEEE standard assembly language


Quoted text here. Click to load it

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 "<type> 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


Re: Atmel AVR assembler OT:IEEE standard assembly language
On Mon, 25 Jul 2005 22:35:42 -0000, "Jean Castonguay"

<snip>
Quoted text here. Click to load it
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

We've slightly trimmed the long signature. Click to see the full one.
Re: Atmel AVR assembler OT:IEEE standard assembly language

Quoted text here. Click to load it

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

Re: Atmel AVR assembler OT:IEEE standard assembly language
On Tue, 26 Jul 2005 00:28:41 GMT, Alex McDonald

Quoted text here. Click to load it


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

We've slightly trimmed the long signature. Click to see the full one.

Site Timeline