Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>   =

>> By my experience, most projects end with a good deal of unused program
>> memory space, so I don=B4t worry much about final code size. These days,
>> it is even less important as the program memory of the new devices is
>> getting larger at the same time their price is dropping.
>>     =

>
> This is nonsense of course.  There will always be high volume cost sensit=
ive
> projects pushing the limits.  If the parts get more capable and cheaper,
> more things will be crammed in or cheaper parts used.  The majority of
> projects aren't cram jobs, but a significant fraction do bump into limits.
> Since those are generally high volume projects, they account for a much
> larger fraction of microcontrollers sold.  In fact, I'd say such projects
> dominate in terms of units produced.
>   =


For some very critical cases the assembly language may be better, but if
the object code fits in the program memory, it doesn't matter if it
takes 50%, 70% or even 80% of the memory.
It is good to have some spare space for future enhancements, but in the
case you mention of a high volume project, it is OK even if it takes
100% of the program space.

>> And it really is easier to debug C code than assembly
>>     =

>
> I have found completely the opposite.  At least with C18, I can rarely get
> MPLAB to show me local variables, step cleanly from one source line to the
> next, etc.  Debugging the C18 parts of a mixed C18/MPASM project is *much*
> harder than the MPASM parts.
>   =


MPLAB is indeed buggy, but it is not the only available option. Again
you resort to a very specific case to make your point. You are taking
MPLAB SIM/IDE bugs as if they are due to the C language, and not of the
buggy implementation done by Microchip.

With a good IDE and debug Tool, all the advantages of C pop to the eyes.

You appear to be locked to a single vendor and architecture. If you had
to design using AVR, ARM and x86 (software only) besides PIC, you would
understand the need for high-level languages.

>> and to change
>> something  in it after some months or years after it is finished.
>>     =

>
> Then you need to learn to document your code better.  This is not a langu=
age
> issue, but a code discipline and documentation issue, and applies to all
> languages.  I've seen some horribly obtuse C code.  You can make a mess in
> any language, and you can also write clear code.  Don't blame the languag=
e.
>   =


Your argument only stands if you assume I document poorly my C code and
you document your assembly code well. Just suppose somebody very
disciplined write and document both the C and assembly code, which one
is more compact, has less lines of code and is easier to understand?

What if you are studying somebody else's code, isn't it easier to
understand if it is in a high-level language? Specially if you don't
know the architecture?



Best regards,

Isaac

__________________________________________________
Fa=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger =

http://br.beta.messenger.yahoo.com/ =


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist