Re: Asm source code page?

On 13/01/16 05:34, Onestone [email protected] [msp430] wrote:
>  
> 
> I do so want to go for six shooters at sunset, but mostly you are right,
> however this presupposes the C writer is able to write efficient code,
> because without that the compiler, no matter how efficient, is of
> limited help. The number of times I see people do something that needs a
> division, lets say an average, and they pick some arbitrary value such
> as 11, when 8 or 16 makes more sense and codes cleanly. No compiler can
> make up for dumb thought processes, whereas assembler tends to make you
> think more in line with how the CPU hardware works, at least when I
> write software that's how I think, basically track the operands through
> the hardware in my thoughts. Similarly C programmers tend to be in love
> with floating point, when integer is more accurate, and faster. In 40+
> years I've very rarely had the need to revert to floating point, yet
> most of the C programs I see for micros use it whenever the program has
> to handles numbers.

That's a good point, and you are absolutely right.  I think that the
best way to learn to write good C code for embedded systems (actually,
good C code in general) is to do some assembly programming first.
People who come to embedded C programming from assembly upwards write
more efficient code than people who get there from Java, C#, Python down.

But there is also a similar effect the other way.  While those with a
background in PC programming will divide by 11 or use floating point
without thought of the consequences, people with an assembly background
(and even more so, people programming in assembly) will avoid these even
if they are actually the best way to handle the problem.  Sometimes
floating point is the most convenient way to get correct code, and it
doesn't matter if the operation takes 1 ms instead of 10 microseconds
using scaled integers.  An assembly programmer, or a C programmer who
thinks in assembly, would avoid the floating point even though it means
a good deal of unnecessary work.

It is not easy to get the right balance here - but if this job were too
easy, it would be no fun!  On the whole, people who have done /some/
assembly programming are better qualified to write embedded C than
people who have not done so, but /any/ programmer of /any/ type of
system will benefit from working on a variety of programs on a variety
of systems using a variety of languages.

> 
> So while I agree that in the hands of a good programmer C should be
> quite fast and compact, I suspect that the number of C programmers out
> there who are capable of making use of these features are as few and far
> between as assembler programmers of any ilk.

This is all gut feeling rather than evidence based, but I think the
percentage of good, mediocre and bad programmers for any given language
is fairly independent of the language.  I would rather have a mediocre C
programmer, or even a bad C programmer, than a a mediocre assembly
programmer - because a non-expert C programmer might write inefficient
code, but he is less likely to write /incorrect/ code.  And correctness
trumps efficiency every time.  (And non-expert assembly programmers
write inefficient code - at least as badly as non-expert C programmers.
 I have seen plenty of astoundingly bad assembly code.)

When working in teams, it is also much easier for one expert C
programmer to guide and help a number of mediocre C programmers - code
reviews to weed out particularly bad code, help on the "difficult bits",
etc.  This is a lot harder if everyone is doing assembly - it is far
harder to understand most people's assembly code than their C code when
doing reviews, and there are many more "difficult bits".  (Again, this
is gut feeling without proof.)


> However a good compiler can
> make an average C programmer look a lot better than they really are. 

If the resultant program is good enough for the job, does it matter if
the programmer did a good job, or if the compiler did a good job?  When
doing professional work - someone is paying for your time and effort -
then "good enough" is good enough.  Perfection is a waste of somebody's
money.  If the motor has to turn at 1000 rpm, then hiring a better (and
more expensive) C programmer, or letting an assembler programmer spend
four times the development time in order to get 2000 rpm out of the same
chip is a waste of money.  It means you have done a /worse/ job, not a
better one.

> I
> truly believe that the higher level language you program in the lazier,
> sloppier and less efficient most people get because they can, without
> much fear of being found out, and if it doesn't work just throw a bigger
> faster processor at it.

Absolutely true - but lazy and sloppy are /good/ in the right context.
When I write PC code, most of it is in Python.  It is far cheaper for
the customer to buy a faster processor than to pay me to write tens of
thousands of lines of efficient C code rather than a few hundred lines
of quick-and-dirty Python code.  High level languages exist to insulate
you from the low-level details, giving a different balance between
development time and run time.

I believe that working with a variety of languages at different levels
(both higher and lower level than their main language) makes a
programmer more aware of this, and better able to choose the right
balance for the task in hand.

> 
> I get it, but don't want to be a part of it, and don't have to be so I
> shall plod along with the rest of the dinosaurs waiting for the next
> major extinction event to come along.

In all discussions about what is the best language or development
methodology, it is important not to forget the developers' preferences -
a happy assembly programmer is more use than an unhappy C programmer!

mvh.,

David


> 
> Cheers
> 
> Al
> 
> On 13/01/2016 9:48 AM, David Brown [email protected] [msp430] wrote:
>> 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]