C in a uC... what were they thinking??

[dwight]

These are good meaningful comments but it clearly shows the
desire to have an assembler that allowed multiple statements per line.
The comments could just as easily been put at the break comments you
had as empty lines, in many of the cases.
Dwight

[GARTHWILSON]

dwight wrote:

These are good meaningful comments but it clearly shows the
desire to have an assembler that allowed multiple statements per line.

I believe I've seen such assemblers (and Forth assemblers do it routinely); but again the power of assembly-language macros goes widely ignored, misunderstood, and unused. Used properly, macros can dramatically raise the level of the language, with, in most cases, no penalty of any kind, while improving programmer productivity and software maintainability, and reducing bugs. Macros could definitely be putting a dent in the popularity of HLLs.

I'm not saying there's no place for HLLs, only that some of the criticisms against assembly language are often false charges.

[dwight]

As for macros, I rarely use a branch statement out side of
some type of flow structure macro.
No more L1, L2 etc labels.
Dwight

[BigDumbDinosaur]

dwight wrote:

These are good meaningful comments but it clearly shows the desire to have an assembler that allowed multiple statements per line.

No such desire here. Even if I had such an assembler I would not place multiple statements on one line. Assembly language isn't BASIC—run-on lines in assembly language make it easier to make mistakes that are hard to pinpoint, with essentially no gain in typing speed. Also, the ability to clearly read each statement has become very important to me in recent years due to deteriorating vision.

Quote:

The comments could just as easily been put at the break comments you had as empty lines, in many of the cases.

Nope. The reason for the breaks is to clearly delineate blocks of code, such as the FIFO processing loop. Also, I always put a break after a branch instruction, as that is a "fork in the road" in the logic flow and thus is easier to pinpoint in large programs.

POC V1.1's firmware runs to over 12,000 lines of source code. POC V2's source code will be even larger (it's already near 14,000 lines) and more complex. Without rational formatting, it would be a reading quagmire, especially if lines contained multiple statements.

GARTHWILSON wrote:

I believe I've seen such assemblers (and Forth assemblers do it routinely); but again the power of assembly-language macros goes widely ignored, misunderstood, and unused. Used properly, macros can dramatically raise the level of the language, with, in most cases, no penalty of any kind, while improving programmer productivity and software maintainability, and reducing bugs.

I haven't used any macros in POC's firmware, other than those that synthesize 65C816 instructions. For some strange reason—likely due to having written 6502 assembly language for some 40 years—I have no trouble visualizing loops and similar program structures, so have not found an incentive to use macros in such areas. However, I do use macros in my application software to lessen the work of calling functions and processing multi-byte numbers. For example, it's definitely easier (and more mnemonic) when printing a character to the console display to write prntchra 'A' than (in the case of POC V2) write the following:

Code: Select all

         LDA #'a'              ;char to print
         TRAP _b_writsioa      ;write char to console

With the above encapsulated in a macro I am much less likely to miss a required parameter or otherwise upset the apple cart. The macro makes sure the right API index is specified during the API call. The assembler will complain, of course, if the parameter to prntchra is missing or is not a single byte.

By the way, the TRAP instruction itself is a macro:

Code: Select all

TRAP     .macro .api
         .if .api = 0 || .api > maxapi
             .error ""+%1+": API index out of range"
         .else
             PEA #.api             ;API index to stack
             COP #$00              ;call API handler in BIOS
         .endm

Sure beats typing in all that gibberish with each API call.

[whartung]

Oneironaut wrote:

Recently, I had the job of taking over someone's prototype development, and part of the system included C code to read RAW data from an SD card. Having recently written my own SD card code for the 6502, I figure it would be an easy project to do. It took me only a few hours to get SD access on the 6502 using assembly, and it is minimal code.

Well, after 2 days I finally gave up!

Quote:

I eventually downloaded the PIC assembly list and just coded the thing from scratch in 3 hours.

If you didn't understand the original code, how do you know your replacement code replicates its behavior?

Quote:

The code went form at least 400 lines to about 30, and program memory usage was way down.

What did you do with the newly freed up memory?

Sounds to me that the C code was simply doing more than it should, it may even be likely that the code was imported from another project (perhaps even another processor) that also needed an SD card. If the solution could be expressed with 30 lines of assembly, it could likely have been addressed with less C code. It perhaps may not have taken the C developer 3 hours to develop it either.

Quote:

I have never been able to figure out why anyone though that C on a small uC was a good idea.

People use high level languages because HLL are better at manifesting abstractions. And computer software is all about developing the appropriate level of abstraction for the task, and getting the problem space implemented within that space. You may notice that when whoever tasked you with the problem did not represent it as a list of mnemonics, but more likely as simply a bunch of boxes and lines and arrows, because humans think and work much better at that space than in the realm of carry flags and bit shifts. It's why we tend to use generous amounts of white space, especially in assembly level programs. It's a reason (interpreted) BASIC is chastised as it's actually more difficult to use expressive white space and code layout to represent structure and data flow.

Economy and efficiency of code become less and less important as the capability of the processors get better and better. At best, they're necessary for a small fraction of the overall code base, becoming a "nice to have", but "don't spend any time on it". Cue up the treatises decrying pre-optimization. The fastest, smallest code in the world may well still be stuck spinning and waiting for the next clock from the slow SD card.

Seems to me your example is more a discussion on the other developers understanding of the task at hand rather than anything to do with C. Having just done this yourself, you may have been able to bring keen insight the original developer lacked in how to pursue the problem. You said so yourself, it certainly wasn't your expertise in PIC assembly.

[GARTHWILSON]

whartung wrote:

Sounds to me that the C code was simply doing more than it should, it may even be likely that the code was imported from another project (perhaps even another processor) that also needed an SD card. If the solution could be expressed with 30 lines of assembly, it could likely have been addressed with less C code. It perhaps may not have taken the C developer 3 hours to develop it either.

That's part of the problem, as I see it, with C; not the C itself, but the idea that everything is done for you somewhere, and all you have to do is download a library. You get a bunch of stuff you don't need, and maybe not exactly what you do need, and there's often little care to check for efficiency or bugs. Sharing code is good. Carelessness is not. It's similar to times I've had in my work where someone said I should look into a particular IC because it supposedly already does everything for you, and you look into it and find out that it's no match for your niche application.

[dwight]

I am not particularly a C fan. Still, for the arduino, it is reasonable.
As was mentioned, the libraries may be what you need. They also may be
over bloated and they may have bugs in them.
On the few tinker projects I've done on my arduino, I've often looked at the
source code for the library and extracted or modified the parts I needed.
In one case I even saw some bugs ( at least the code didn't properly match
the manufacture specification but didn't seem to do harm ).
One may be used to the old style of assembler and comfortable with it
but it is the major reason why many find it hard to get started in it.
The proper use of white space, both vertical and horizontal makes coding
that needs less comments and easier to maintain.
The code should say what it does. The comments should say why your doing
it. Choice of label names and routine names is the best first level of commenting.
Like the example of the FIFO. A single line comment stating that:

If the input and output pointers are different, I need to handle the data
until they are matched again.
...code...

Would clearly make the code clearer and made the code easier to maintain.
Not everyone is familiar with your coding style.

[BitWise]

dwight wrote:

I am not particularly a C fan. Still, for the arduino, it is reasonable.

Arduino programs are written in C++ but the basic tooling hides that to some degree. When you write a library you see it fully.

I'm always amazed that the generated code actually fits on an Arduino. The C++ libraries on UNIX and Windows generate masses of code bloat.

[cbmeeks]

Remember folks...one man's code bloat is another man's highly-optimized code.

We've all had stories of taking code someone else wrote and making it more efficient. It's fun and makes us feel good. But unless you're in the top 1% of programmers in the world, or hand assemble raw hex codes for a living, there's a good chance you're using someone else's code bloat and that's not always a bad thing.

Being a Java programmer, I'm surrounded by code bloat. Some of it's mine (I get better over the years) and some of it's from open source libraries I use.

But I'm sure as heck not going to write my own TCP/IP stack in hand-coded hex binary files for the bragging rights of saying I'm better. Sometimes, you have to use other people's code bloat to get a project done so that you can move on to something else.

The programming world is full of "Michelangelo's" of software that never seem to get anything done.

Anyway...just saying.

[sark02]

Yeah, I disagree strongly with the "other people's code is slow and bloated" sentiment. And the idea that 'C' libraries are somehow intrinsically bloated is nonsense I only hear from people trying to justify their own choices or push their own preferences. Are there bloated libraries? Sure. Are there instances of other people's code that is slow? Of course. Does that apply to every language and environment since the invention of computers? Yup.

Stand on the shoulders of giants... you'll see farther.

[cbmeeks]

sark02 wrote:

Yeah, I disagree strongly with the "other people's code is slow and bloated" sentiment. And the idea that 'C' libraries are somehow intrinsically bloated is nonsense I only hear from people trying to justify their own choices or push their own preferences.

I think you misunderstood my comments completely. My whole point is that there is always going to be code bloat. There will always be someone better (who writes better, less-bloated code), etc. Additionally, my point is that it's silly to try and reinvent the world on everything you do. Did you write your own web browser to post to this forum? Did you write your own OS, network stack, etc.?

Again, my point is that sometimes you have to choose your battles. Sometimes, you have to use bloated, garbage code because nothing else exists or it's not worth the effort to fix it. Sometimes...you just have to get something done and move on.

I try *VERY* hard to write efficient code. But I know for a fact there are better developers than me in the world that would complain how "lazy" I am. It's all relative.

sark02 wrote:

Stand on the shoulders of giants... you'll see farther.

I do that on a daily basis. Been doing it for over 30 years.

[barrym95838]

cbmeeks wrote:

... The programming world is full of "Michelangelo's" of software that never seem to get anything done.

Anyway...just saying.

afeb88c226d9810cf4348d8292ec2915450bd5f38b3f89b709179f8ac9e167f4.jpg (15.09 KiB) Viewed 1269 times

Mike B.

[sark02]

cbmeeks wrote:

I think you misunderstood my comments completely.

I [stand on the shoulders of giants] on a daily basis. Been doing it for over 30 years.

I was actually agreeing with you. I saw your post and wanted to add my own thoughts.

[cbmeeks]

barrym95838 wrote:

afeb88c226d9810cf4348d8292ec2915450bd5f38b3f89b709179f8ac9e167f4.jpg

Mike B.

LMAO!!! Actually, I used Curly as my avatar for many websites for years. I've recently switched over to Larry. I have an unhealthy obsession with the Stooges. All SEVEN of them (and no, I'm not counting Ted).

sark02 wrote:

I was actually agreeing with you. I saw your post and wanted to add my own thoughts.

Oh, then it was me that misunderstood. It happens sometimes. Second time this year actually. LOL

[barrym95838]

cbmeeks wrote:

... I have an unhealthy obsession with the Stooges ...

Curly was remarkably brilliant. Curly Howard, John Belushi, Chris Farley, Keith Moon ... I'm a fan of all of them for their remarkable brilliance ... perhaps more brilliance than could be safely contained in a mortal body, leading to their untimely passings ...

Mike B.