On Sat, Apr 05, 2014 at 06:54:58PM -0400, Josh Koffman wrote:
> Hi Jan-Erik,
>=20
> On Sat, Apr 5, 2014 at 6:21 PM, Jan-Erik Soderholm
> > 3.
> > If the (source) code is hard to follow, it realy doesn't
> > matter what it will run on when compiled. Hard-to-read source
> > code is always hard-to-read source code. And that is of course
> > not something specific to C. :-)
> >
> > Your *compiled* C code will probably still have a lot of
> > GOTO's all over the place, maybe even more then before.
> > But that is only to implement the higher lever constructs
> > available in C as "case", "while", "if" and so on.
> >
> > Some says that properly written C code will never see any
> > need for a GOTO... :-)
>=20
> I've run across that as well. I guess as I get more comfortable I will
> stop reaching for the "crutch" of a goto.

I would implore you to force yourself to write without it. It (along with
global variable for everything) is one of the fastest bad habits to fall
into.

Give us a couple of example where you've used a goto. It can then be used
to show how to properly construct a higher level flow control construct
around it.

It is important not to simple use the higher level language as a wrapper
around your assembly language ideas. Most modern programmers rarely run
into this problem because they almost always learn the higher level
language first and can easily fall back into their abstractions after a dip
into assembly. It's a bit tougher the other way around because assembly
programmers are used to handling all the details.

>=20
> > 4.
> > There is nothing stopping you to continue handling your
> > peripherials just as before. Any C compiler for PICs should
> > have syntax for dealing directly with registers and "bits".
> > It just comes in a nicer "package"... :-)
>=20
> I wonder if it makes my code a bit more portable as well, since if the
> peripheral macros are defined correctly, they should work
> automatically when I switch chips. That might be a big "if" though.

It's a big "if". It's one of the reasons that libraries get written and
used. They abstract all the details and you deal with peripherals at a very
high level, while the library translates to the details for the particular
chip.

I would not worry about portability until it's an explicitly stated goal.
Even if it's not you can always put a light abtraction layer of functions
on top of periperal access (i.e. open, close, read, write, configure type
functions) then only change the details of those functions if you migrate.

BAJ

>=20
> Thanks!
>=20
> Josh
> --=20
> A common mistake that people make when trying to design something
> completely foolproof is to underestimate the ingenuity of complete
> fools.
>         -Douglas Adams
> --=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

--=20
Byron A. Jeff
Chair: Department of Computer Science and Information Technology
College of Information and Mathematical Sciences
Clayton State University
http://faculty.clayton.edu/bjeff
--=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
.