Re: Asm source code page?

On 12/01/16 22:28, Jon Kirwan [email protected] [msp430] wrote:
> On Tue, 12 Jan 2016 10:04:54 +0100, David wrote:
>
>  ><snip>
>  >gcc will generate better
>  >code than most assembler programmers in many circumstances - assuming
>  >the code has to be written in a clear, understandable, safe,
>  >maintainable manner.
>  ><snip>
>
> Although we've discussed the subject in the long past here,
> this really has very little to do with the current thread
> started by Craig. Craig was interested in "sample code in
> Asm."
>
> While I do think there are a number of related topics to the
> question of sample assembly code (for example, which
> assembler tool is in use so that the appropriate sample
> source can be suggested -- gas assembler is quite different
> from IAR, as we both know), I don't for a second imagine that
> his question should instill a response saying that gcc
> generates better code than "most assembler programers," which
> seems more about uncovering some old sore point than anything
> else. (Besides, there are a few folks here who are definitely
> better than "most assembler programmers.")
>

When I see someone looking for help with assembly, I think it is 
perfectly reasonable to point out the options with compilers.  You have 
to ask yourself /why/ that person is asking about assembly, and think 
can you be more helpful by pointing them in a different direction.

Let's consider the reasons why a person might want to start working on 
an msp430 in assembly.  (Note that I don't know to what extent the OP is 
/starting/ with assembly, but the discussion on choice of assembler 
tools suggest he might be.)

1. They want to learn about the cpu, and see exactly how it works. 
That's great!

2. It's for fun - also great.

3. They want to do something that cannot be done using C.  There are 
/very/ few cases where this is realistic - in most cases, the person is 
mistaken.

4. They want to write the most efficient possible code, and think that 
means assembly.  In most cases, they are mistaken.

5. Assembly is all they know, and they don't want to learn C.  If this 
is for a hobby project, then that's fair enough - but if it is in a 
professional context, then they are not doing a good job.  Writing 
maintainable code in a language that many people understand, and using 
tools that give much greater developer efficiency, means C trumps 
assembly in almost all cases for professional development.  There are 
always exceptions, of course, but exceptions are rare.

6. They think C compilers for small microcontrollers are inefficient or 
limited.  That may be true on some cores, but not on the msp430.

7. They think that C compilers are expensive.  Again, that is true for 
some cores, and it used to be true for the msp430, but it is not true now.


My experience is that most people who choose to work in assembler these 
days, do so for invalid or inappropriate reasons.  This certainly does 
not apply to /all/ people who pick assembler - but it applies to many. 
So in the interest of helping the original poster, it makes sense to 
bring up C as an alternative.  It would be unreasonable to try to push 
it on him if he has good reason to use assembler, but it is a good think 
to suggest it.

So when the OP was asking about different sized multiply and divide 
routines in msp430 assembly, my first thought is /why/ bother?  Write "x 
= y * z;" and "x = y / z;" and let the compiler generate the code.  It 
will make code that is at least as small and efficient as you can do by 
hand - and if it can figure out some of the values at compile time, it 
will do far better than the assembly programmer.  And it will do so as 
fast as you can type a couple of lines of code, and will do so correctly 
- no need to search for sample code, figure out how to integrate it, 
worry about possible mismatches of register uses, and so on.

David



------------------------------------
Posted by: David Brown <[email protected]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[email protected]