> I don't see what everyone gets so caught up on optimization. The real rea=
son
> to move to C is not for efficiency, its for ease of development and porta=
bility.
> Hobbyists (and often engineers too) don't need to to worry about squeezin=
g
> every last bit out of a chip that only costs
> $0.90 to start with. The time spent often outweighs the marginal costs of
> increased flash usage.

The problem has been the C compiler for 8 bit PICs was so bad with no optim=
isation that sometimes the produced code would not run in the intended mann=
er. When you go through the Microchip forums there are examples given where=
 this is the case. People were having problems with their code, and when yo=
u looked at the generated assembly level code it had no hope of doing what =
was originally intended.

> C works just fine on the 8 bit PICs, the only time optimization becomes a=
n
> issue is when you start doing operations that the processor can't do nati=
vely.
> Relative offset addressing, floating point math, division, dynamic memory=
,
> and other advanced features enabled by C should be used with caution.
> However that does not mean that either C or the processor are inherently
> bad. The compiler only does what you tell it, if stick to basic basic ope=
rations
> like you would do in assembly (writing to registers, loops, 8 bit integer=
 math)
> there shouldn't be an issue at all.
> <end rant>

Yes it does work fine on 8 bit PICs - when the compiler produces code that =
will at least do what the coder intended.



--=20
Scanned by iCritical.

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