If I recall correctly, my very first post to the PICLIST was adding my two cents worth to a discussion similar to this (which was teetering on the brink of war), so I might as well continue the tradition. I recently worked on a project that had the following two constraints: 1) The hardware was designed AND built, so there no no changing it, and 2) the engineer manager said it WILL be written in C. Given that the hardware was the main constraint, I modeled the problem (in Excel) and proved that the C compiler offered for the task could not generate the code required to produce the desired output from the PIC. The only to permit usage of the compiler would have been a couple of hardware changes (most notably a change to a faster crystal). The project, which was really very small code footprint, could only in done in assembly. My point? I think many on this list would agree that you should analyze the application BEFORE making a decision to go either way. Don't ONLY code in assembly language OR C OR JAL (OR "fill in the blank with your facorite language") all the time. Pick the best solution for the given problem. Douglas Wood Software Engineer dbwood@kc.rr.com ICQ#: 143841506 Home of the EPICIS Development System for the PIC http://epicis.piclist.com ----- Original Message ----- From: "John Dammeyer" To: Sent: Thursday, February 06, 2003 5:21 PM Subject: Re: [PIC]: C Language V's Assembler > Hi guys, > > It's been a while but I'm back on this list. > > I'll add my two cents on this subject. A disagree with the concept that > writing in C means one should only think in C. That's a quick way to > create code bloat applications in the small single chippers. > > Each compiler has a quirk or two and examining the code created with > various 'C Language' constructs that do the same thing but generate > different code leads to shorter, tighter applications. Yes, it results > in sometimes producing C applications that don't look as much like C but > more like structured assembler but consistency does end up making the > programs just a readable. > > For example, I was handed some hardware which had two LEDs connected to > two I/O pins. Pulling the pins low turned on the LED. But also > connected to the same pins were two buttons that pulled the pins low. > To read the button state meant turning off the port bits so the lines > went high. Then reading the pins, and then restoring the state of the > outputs to leave the LEDs on/off as before. > > Added to the complexity is that the function had to return a bit set in > a different position from the physical bit position of the LED/Switch > input. First crack with thinking in C produced horrendous code. Only > by examining what the assembler code looked like and trying a few > different options was I able to create a very tight chunk of code that > prevented any LED flicker while testing the keys. > > BTW, The compiler was the TASKING 8051 Rev 6 and didn't do as nice a > job as BYTECRAFT MPC for quality of code. > > Cheers, > > John Dammeyer > > Wireless CAN with the CANRF module now available. > http://www.autoartisans.com/products > Automation Artisans Inc. > Ph. 1 250 544 4950 > > > > -----Original Message----- > > From: pic microcontroller discussion list > > [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Andy Kunz > > Sent: Thursday, February 06, 2003 2:59 PM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: Re: [PIC]: C Language V's Assembler > > > > > > >Any time when I write C code I think in C > > >And I do not care about what is really happening > > >Inside of pic and C generated asm is hard to read > > >All labels are numbers hard to fallow. When any person starts writing > > > > Well it isn't intended to be viewed by you, so complexity of > > reading is > > immaterial. The fact is, good optimizers produce code that may not be > > anything at all like you would write. I don't have a problem > > following > > Hitec's labels around - they are very straightforwardly > > created and make > > lots of sense. > > > > >to know more about almost every thing in detail. You > > >Started long time ago you learned every thing your case > > >Is different. > > > > I would say that most embedded programmers start in assembly > > and move to C > > as project complexity and size increases. Therefore my > > situation is the > > common one, not the "different" one. > > > > Andy > > > > -- > > http://www.piclist.com hint: PICList Posts must start with ONE topic: > > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > > > > > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads