AVR-Chat

David Kelly wrote:
> On Thu, Jan 15, 2009 at 01:06:01PM -0000, brewski922 wrote:
>> Ditto Dave.
>> I am sure most C devoties would argue that to get down and dirty or 
>> write the smallest and/or fast code assemble is the way to go.
> 
> I do not consider myself to be a "C devotee", altho C is among my
> preferred tools. There is a big question as to just how small and how
> fast is small and fast enough? On AVR, HC11, and HC12, on examination of
> assembly code I have found C and assembly to be roughly equal in speed
> and code density.
> 
>> And most assemble folks would say to get the program completed in the 
>> least amount time and/or most cost effective do it in C.
> 
> The larger the project the more important it is to abstract parts of it,
> then put it aside and forget it while working on other parts. That is
> something that C does very well, and is exactly what C++ is about taking
> to the next level.
> 
> When projects get big, C often generates smaller code because one was
> abstracting concepts and often finds ways to reuse more portions than
> the assembly programmer.
> 
>> So both of them have their strong and weak points.
> 
> There really isn't any weak point to C. The only gripes I have at times
> is when a compiler calls an intrinsic function for something relatively
> simple like uint32_t i++. Or for a 32 bit comparison (HCS12,
> CodeWarrior). Have found there that I can put the 32 bit variable in a
> union and separately compare uint16_t's in the same space and time as
> the compiler can setup the intrinsic function call. But guess what? This
> is exactly the sort of thing one would have to do in assembly.

The best thing about most HLLs compared to assembler is that you can chop
and change great stretches of code and see what you're doing and have the
system running again easily.

With asm, you have to tediously study one great column of code before and
after you do any chopping and pasting. HLLs have a 2D visual aspect to it.