On Mon, 3 Mar 2008, PAUL James wrote:

> 
> Rikard,
> 
> I can't help you with your request, but you have brought up a point that
> I have answered before.  That is, 
> you have come across something that I have run into in the past.  And it
> further justifies my opinion that
> HLL's for the PIC series is not the big boon that they are made out to
> be.  I hear people often saying that the Microchip instruction set is
> "Arcane" or "Cumbersome".  However, I think it is just fine.  I think
> the HLL's
> Are the Arcane, Cumbersome ones.  Therefore, I still do most of my
> programming in assembler.   Only if the 
> Customer requests an HLL be used, do I depart from my norm of assembler.

If you've been programming in assembler for a long time chances are that 
you'll have a lot of code hidden away somewhere which you can reuse in 
some way or other. Whether it is a set of subroutines, macros or just 
application code that you can cut and past I'll bet there is a lot of it.

Over time you may even develop a style that lets you slot pieces together 
like building blocks - a protocol that spcifies how data is passed around 
between the subroutines and macros.

With all this in place you will probably spend most of your time (while 
developing a new gadget) filling in the cracks between your building 
blocks and optimising bits of code all over the place. In effect you will 
spend more of your time optimising and debugging than writing new code.

Why waste your time doing this - this is what a compiler does, and it can 
try lots of different combinations of optimisations each and every time 
you make the smallest change. It wont forget that a variable has changed 
from an 8 bit integer to a 16 bit integer at some obscure point in your 
code (e.g. when you are passing it to a macro). It wont complain at having 
to change everything just to squeeze one more byte out of your executable.

A big problem that many assembler programmers seem to have with regards to 
using HLL is what they perceive to be the verbosity of the HLL source. 
They resent having to write lots of HLL source code that gets compiled 
down to maybe a trivial couple of machine code instructions. What they 
fail to understand is that the HLL is actually allowing them to tell the 
compiler things about the program that the assembler programmer cannot.

In an assembler program a lot of info remains in the head of the 
programmer. The programmer may know that at a given point in the 
executable a register is being used as a loop counter but the assembler 
itself does not. Whereas in a HLL the compiler knows about loop counters, 
it knows about the code inside a loop, it knows if the loop counter is 
being used as an index. It knows how to perform optimisations based on all 
this information - and when the program get modified it knows how to 
compensate. The assembler programmer has to do all of this the hard way 
and possibly do a lot of testing to ensure that all the changes behave as 
expected.

Yes you may need to write a lot more source code in a HLL to do something 
trivial BUT there is a lot less time spent filling in cracks and tracking 
down obscure bugs that arise due to a small code change.

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