C vers Assembler

[Marke]

I was recently in a discussion with a group of younger engineers who have a problem with code space in a micro.
The code including I2C and serial communications is all written in C and the code space limitation is a major problem for upgrading the product.
I suggested that I would rewrite the stable parts of the code (now well proven) in assembler to produce faster and tighter code as I have done many times over the years. - works well for me, takes a bit longer, but the algorithm and interface are proven at this point.

I was surprised with the reaction that I got, basically, while this approach may have been true in my day, modern C compliers produced smaller code than assembler, so my suggestion would not work.

This is news to me, and to others that I have spoken to.
Any comments?

Mark Empson
Advanced Motor Control Ltd

 

[MacGyverS2000]

While modern compilers have improved their output significantly over the years, it's rare they can get to the level of hand-coded assembly. In fact, it defies basic logic that a compiler (which has to make numerous assumptions along the way) would be capable of beating hand-coded assembly, and your colleagues should be smacked for making such an illogical comment.

In most cases, the ROI for hand-coding versus compiler is often negative, so many choose to stick with compiler output. However, in your situation, you need the space, so hand-coded assembly is pretty much the only way to go.

That said, rewriting "well proven" parts of code also places them squarely back into the non-"well proven" box, so don't argue that point too loudly. You may get a few bytes out of peripheral management code like I2C, but since you're already pretty close to the registers at that point, the gain will likely be minimal in the grand scheme of things. Where you will see your major improvement is in complicated pieces of code, ones where the compiler could not make the correct assumption and therefore added in a lot of dead weight. Looks for sections of repeated code that could be turned into function calls, nasty if/then/else statements that go on forever, etc. Of course, with well-written code, this kind of stuff shouldn't be in there in the first place. Sometimes, refactoring your codebase is a better solution... how can you solve problem 'X' using a different (but shorter) method, like calculating a value instead of using a look-up table.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

I agree, it's physically impossible to do better than customized, hand-optimized code, since there must exist a minimal set of instructions that implement the desired function. C is supposedly on the order of 1.5x pure assembly code; there still may be routines that could benefit from using processor-specific instructions, but you run the risk of making the code non-portable. That said, most programmers don't know how to do assembly, and there may be a fear factor there. But, new custom assembly is NEW code.

I also agree than re-visiting the basic assumptions and architecture of the code is possibly beneficial. We once had mathematical transform code that could be reduced in complexity by 98%, just by exploiting the symmetry of the hardware design.

I would assume that your compilers are sufficiently optimizing that it strips out library routines that aren't being referenced, but there still may be a few holdouts in any linked libraries.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[MikeHalloran]

It is physically possible to make code smaller than hand-coded assembler, using the ancient language FORTH. ... which basically turns high level code into a list of addresses of atomic subroutines, which are executed in sequence by an 'inner interpreter'. The overhead of all the calls and returns makes it a little slower then hand-coded assembler.

I have even seen a crew build a bunch of 8035 code 'by hand', as lists of addresses of atomic subroutines to be executed by a tight loop, without realizing that they had almost reinvented FORTH, the hard way, at considerable expense. The product in which that code was embedded was fairly successful, but had no code space to spare for enhancements, and bug fixes were a super bitch.

I am not aware of any C compilers, modern or not, that can match the density of FORTH binaries. Some of them can beat the speed.





Mike Halloran
Pembroke Pines, FL, USA

 

[MacGyverS2000]

I can beat that, Mike... in my language, there's only one instruction, 'go'. The "interpreter" takes care of the rest

Dan - Owner

http://www.Hi-TecDesigns.com

 

[MikeHalloran]

I had a boss like that once.


Mike Halloran
Pembroke Pines, FL, USA

 

[xwb]

Forth is hard to beat for density. Not so hard to beat for speed. If you look up indirect threaded code, you'll get the general idea of how it works. There is also a variant called knotted code which is even more compressed but that term hasn't been used since the early 90s so you probably won't find anything on it on the net.