35% smaller, and 14% faster code!

 35% smaller, and 14% faster code!

There is a new 8051 C compiler in beta test that beats Keil's compiler by 35% code size, and 14% speed, on the Dhrystone benchmark. And, there is no need to select a memory model or use special keywords to control data placement.

More details here: http://www.htsoft.com/forum/all/postlist.php/Cat/0/Board/silabs8051beta

 RE: 35% smaller, and 14% faster code!

1) No reference to "best choice" of optimizing flags for the two compilers.

2) Too small application to show difference in code size - remember that size of RTL affects small projects more.

3) How much of the code optimization results in speed changes for other applications? The Dhrystone isn't exactly relevant for an 8-bit microcontroller with 1-bit instructions...

They really have to produce more information before making any claims in one direction or the other. Compiling an application that makes use of a lot of one-bit variables and compare between two compilers, and then compila a program using a lot of 16-bit orh 32-bit variables and you will see that the comparisons will vary a lot. Code size and speed can only be deduced from a significantly large code base of very varying - but applicable - code.

 will it debug

I am sure, anyone with enough experience can make a compiler that will make faster and more compact code. who gives a hoot if the result is not 'uniquely breakpointable'. Th result from Keil can be much better if you use a higher optimization level, buy who in his/her right mind would use code the emulator can not 'uniquely' breakpoin on. Sorry, I have now offended a lot of people, but debuggability is far more important than those last few percent efficiency. What really offend me is that nobody (yet) has made a compiler/linker/optimizer that fully maintain program flow and is optimized in all other respects.

Erik

PS Clyde, do you really think it is apprpiate to promote your stuff on a website run by a competitor?

 RE: will it debug

"buy who in his/her right mind would use code the emulator can not 'uniquely' breakpoin on"

Important for people who are incapable of writiting functional code in the first instance I would imagine!!??

 RE: will it debug

"but who in his/her right mind would use code the emulator can not 'uniquely' breakpoin on"

Important for people who are incapable of writiting functional code in the first instance I would imagine!!??

and totally unimportant for those that do not mind occasionally ending up in a debugging nightmare.

I recall an instance where it was finally found out that the reason optimized (non-debuggable) code did not work and non-optimized (debuggable) code worked was a glitch at the other end of the cable. I would immediately hire anyone that could prove that they would, without an ICE, find any glitch (hardware created or not) in less than 15 minutes.

Of course people like matt black would never have that problem, their code is totally independednt of undocumented hardware glitches

Erik

 RE: will it debug

"Of course people like matt black would never have that problem, their code is totally independednt of undocumented hardware glitches"

I have previously had a rule of not answering the posts of hobbyists and amateurs.

The response Erik given is the reason for that rule. If only I'd not been drawn in by his attempt to inflame!

Maybe Erik should consider going to assembler only projects, then he would be assured that there is no possibility of the compiler corrupting his working C code with optimization.

 RE: will it debug

I have previously had a rule of not answering the posts of hobbyists and amateurs.
only "hobbyists and amateurs" would write non-debuggable code and since i do not, you did not bresk your rule.

the compiler corrupting his working C code with optimization
not a word about 'corrupting' just debuggability. The ability to set a breakpoint in your ICE that will only 'hit' at the actual place, not all places 'theraded' together is essential for fast debugging. Anything can be debugged, that was never the point, but since all research show that 50 - 80 % of the time developing a project is spent debugging, fast debugging is essential.

Erik

dictionary: "debuggability" the ability to debug in a fast and nefficient way.

 Why am I sucked into the ramblings of hobbyists and amateurs ?

bresk
'theraded'
nefficient

If you write code with the same cavalier manner in which you write your responses, then I can understand your dependance on debugging tools; however, even a lowly optimizing compiler normally picks up typographical errors like these.

Also, 'debuggability'; whose dictionary do you use?

 RE: Why am I sucked into the ramblings of hobbyists and amateurs ?

Also, 'debuggability'; whose dictionary do you use?
none just tried to emphasize that I did, by no means, try, by 'debuggability' to indicate that I did not consider anything could not be debugged, but were referring to the ability to do efficient debugging (ICE).

Re cavalier manner ... typographical errors
I am 'redecorating' and thus having the keyboard in my lap. also, a person should be able to 'read through' a few errors, I would never expect a computer to do so.

Re "amateur - hobbyist" I have produced working systems (not flawless in all cases, but with very few flaws in all cases) for more years than I am willing to admit, let me just say, some were before the microcontroller even existed.

Erik

To consider their code so superior that debuggability should not be a concern is a typical attitude of mateurs and hobbyists"

 RE: Why am I sucked into the ramblings of hobbyists and amateurs ?

"I have produced working systems (not flawless in all cases, but with very few flaws in all cases) for more years than I am willing to admit, let me just say, some were before the microcontroller even existed."

Likewise, but I prefer to be more rounded when it comes to saying what is best - There is no perfect 'one fits all' solution and I would have expected someone with your claimed experience to appreciate that fact. I do not, in general, see the requirement to use ICE or even consider it when initially developing code. If there is an awkward problem, then I get it out - Else I prefer to study the code.

End.

 RE: Why am I sucked into the ramblings of hobbyists and amateurs ?

I do not, in general, see the requirement to use ICE or even consider it when initially developing code. If there is an awkward problem, then I get it out
and what are you going to do then if the optimizer has 'threaded' your code and you can not set a 'working' breakpoint.

1) there is no issue "when initially developing code", my sole point is optimizer 'threading' vs breakpoints
2) debugging what is not "an awkward problem" need no special measures
3) if your method is not so that "an awkward problem" can be debugged in a reasonable time, you will miss some deadlines.

Erik

 RE: Why am I sucked into the ramblings of hobbyists and amateurs ?

I've seen too many well qualified graduates who insist on going straight for an ICE when they see a problem, rather than looking for logic errors in their code.

There's no real substitute for thinking and no excuse for laziness.

 you forgot the quotes

I've seen too many "well qualified" graduates who insist on going straight for an ICE when they see a problem, rather than looking for logic errors in their code.
you forgot the quotes. I have seen many that were "well qualified" as far as academia goes, but not in the real world.

There's no real substitute for thinking and no excuse for laziness.
I wholehardedly agree.

as to your first point, this is not ICE, but the scope. Many many moons ago, when scopes were slower, our best hardware guy and the undersigned 'universalist' started hunting a "once a day" hit. Although software was blamed (I had recoded the process to run 4 times faster) I had no doubt it was hardware. Finally we decided to use the "DNA scope" and looking through the schematic of a peripheral with as far as I remember ~400 TTL gates found a possible pulse that the scope could not see. We removed the possibility of that pulse and the unit worked. Approaching the original designer he stated "that can not happen" and pointed to typical values in the datasheet AAARGH!

now, as far as "going straight for an ICE", the ICE is never going to tell you what is wrong, but it can be very helpful in finding where to look. E.g. when 2 processors communicate (I am currently having 8 running in tandem) the ICE can tell you whether it is transmission or reception. My main 'beef' with those that are "going straight for an ICE" is not their debugging method, but those types often "insert a fix" instead of actually finding the root problem by "looking for logic errors in their code". I always stated that bugs should NEVER be fixed, they should be removed.

Erik

 RE: Why am I sucked into the ramblings of hobbyists and amateurs ?

Mr. black,
Normally I don't intervene in such discussions or should I say - exchanges, and Erik certainly does not require my help - but I find your comments to be simply childish:

bresk
'theraded'
nefficient

If you write code with the same cavalier manner in which you write your responses, then I can understand your dependance on debugging tools; however, even a lowly optimizing compiler normally picks up typographical errors like these.

Also, 'debuggability'; whose dictionary do you use?

Dude, if you cannot deal with Erik's arguments with effective replies, just don't bother...

 Erik's arguments

"...if you cannot deal with Erik's arguments with effective replies, just don't bother..."

Trouble is, I don't see any valid argument, just a predisposition to coming up with a fixated priority with regards to optimization and debugging.

Just because he requires a limited form of optimization, does not mean to say that it is the right one.

It would appear that he is in a minority and it is not justifiable, else compiler writers would already support his requirements.

Going back to dedicated TTL circuit debugging really does not help to emphasise the argument. And yes, I have done my share of TTL circuit debugging, so I feel I know enought to say - It does not have a great deal of similarity to compiler optimizations.

Valid arguments - Phooey.

 well,

Going back to dedicated TTL circuit debugging really does not help to emphasise the argument. And yes, I have done my share of TTL circuit debugging, so I feel I know enought to say - It does not have a great deal of similarity to compiler optimizations.
Well, if you reread the post you will see that the above was in support of YOUR argumnent that thinking is required. That thinking is required, of ourse has nothing to do with optimization, but what we are discussing is debugging and the hurdles the 'threading' optimization put to that

Erik

 RE: Ethics

Erik, I checked the terms and conditions on the use of this forum before posting. There's nothing there that would seem to prohibit it. And I used my real name. What other issues do you see?

Clyde

 RE: Ethics

Your marketing strategy is flawed and, if I may say, rude. Whether there are limitations on commercials here or not, I call upon Keil to remove your post effective immediately.

 RE: Ethics

It is common practice for vendors benchmark their products against themselves and their competitors:

http://www.keil.com/benchmarks/

I have received benchmark results from IAR compared with other vendors in the past.

I have received benchmark results from Keil compared to other vendors in the past.

What's the big deal, that you were notified via a forum post instead of direct mail?

 RE: Ethics

What's the big deal, that you were notified via a forum post instead of direct mail?

No. The big deal is that the OP found no fault in posting this on a competitor's web forum. Had they used their own forum, or a neutrally operated one, that'd be an entirely different story.

 RE: Ethics

"The big deal is that the OP found no fault in posting this on a competitor's web forum."

So, what's the big deal? Ultimately, whether either (the post itself or the OP's finding no fault posting) is a big deal or not will be determined by the thread's longevity.

 RE: Ethics

Since we are talking about thread longevity, we make it a bit harder for Keil to remove the thread by challenging them a bit.

However, I do not think that it is ok to put a brochure in a competitors display rack - I find it unethical. Switching over to the electronic world doesn't make a difference.

An end user may post benchbark results on just about any open forum but a company or its employees should not - repeat not - post on a competitors forum unless it is deemed as required to defend themselves. Marketing own products on a competitors forum is a very big no-no. Big enough no-no that it would probably be best for Keil to leave this thread here. It shows a bit about ethics - if you are the "clyde" that posted the benchmark on the htsoft forum.

 RE: incapable of writiting

I think Per is right... if the post was indeed by THE Clyde Stubbs, Keil will most likely keep this thread.

The meat-n-bones of this thread, the Break-Point-Ability" debug versus "Professionals who are capable of writiting (sic) functional code" positions are indeed fun to read when you have Erik sparing with the Dark Side.

I would [Professionally] hire Mr. Erik Muland over Mr. Matte Black simply due to Erik's acknowledgment that debugging is more important than those last few percentage points of efficiency. To argue the reverse, shows that you are not really designing a system properly and/or do not have the authority to control the design. You are doing somebody else's bidding, and/or promoting an error in logic.

That "last few percent" requirement means that you have one of two problems you are trying to solve:

1) not enough CPU power/speed
2) not enough code-space

Both of these points means that the system was not designed properly to handle the expected loads. There are enough embedded processors out there with enough means (peripherals, memory capacity--on/off chip, MIPS, etc) to meet nearly all of the embedded needs out there. The rare few already have tried to meet such a challenge with limited resources. BUT SOMEBODY made the decision and its part of the engineering challenge.

A new design that requires the C Compiler (a tool) to be far more optimal than what the industry standard has achieved should be a warning about the selected CPU / speed used in the design. ESPECIALLY if the "debug-ability" and "uniquely break-point-able" is hindered. (The experienced professional knows that there is more to "break-points" than fixing poorly written code; such as unit level FQT. Mr. Black, in "professional-eze" FQT is known as "Formal Qualification Testing").

An old design, requiring the extra 35% / 17% improvement, is an indicator that a decision has been made to increase the expectations and requirement of the software system without providing the hardware to support the increased system needs. Usually this is done because of the well known and <sarcasm>Indisputable Management Fact that "Software is Free" and hardware is not</sarcasm>. Other times, it is because of a locked-down design. The point here is that somebody made the decision to boost the system without full knowledge of what that boost really means.

Don't get me wrong, having an increase in performance is great, but to sacrifice the debug-ability is a design error.

In academia (a term used to express the absence of business constraints or in some-cases, reality), the system is redesigned to meet the needs. In the real-world embedded engineering environment, the software must fit within the constraints. But somebody is still responsible for those constraints, and usually the factor inhibiting the speed/code-size redesign is management. They base it upon two things: 1) cost and 2) what sells. Your Engineering Ideals come in behind those.

Cost can be unit-cost to development costs, what sells might be total quantity or total quality. It doesn't matter, but the point is that the Engineer's Ideal of a perfectly designed system found in 'academia' is
not part of the top criteria in the real business world. That is where this Hi-Tech product meets a need. Companies who want to use the same-old product hardware, yet take advantage of the "cost-less" software based improvements will be forcing their engineers to resort to the sacrifices between sufficient tools and sufficient brains.

Yes, highly optimized code can be debugged/validated, but it takes time. The engineer is responsible for the Time = Money factor. The more brains the engineer has, the less time it takes, thus the less money it costs.

Brad's Big Brain must get bigger and bigger as management DECIDES not to improve the hardware to meet the *new* needs. Seeking refuge in a particular tool is just a quick fix to this underlying problem.

The compiler efficiency improvement is highly welcomed, but the compiler must also meet the needs of the debugging/testing phases, and allow Brad's retarded brother (and we've seen them on this forum), to "get the job done."

I think Keil has done a good job in optimization, debugging and testing. So IMHO Mr. Matte Black's comment about "It would appear that he [erik] is in a minority and it is not justifiable, else compiler writers would already support his [erik] requirements." is in error. Keil does it.

I must also state that I have never used, or know the capabilities of, Hi-Tech products. They might be good too.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: incapable of writiting

No new product should require optimum use of the hardware - unless it is a simple product built in large volumes, and it is known that the processor family has variants with larger flash and/or higher CPU frequency so that it is possible to just order a batch of bigger/faster processors to release a premium edition.

But since the lead times for new chips can be quite high, it is dangerous to use a fully slimmed solution even if a bigger/better chip is available. In case a little "gotcha" is found really late in the release cycle, the lead time to get the better chips may result in several months delayed release, probably costing very much more than the price difference between the two chip models (ignoring the goodwill loss from unhappy customers/resellers).

Another thing to think about is to have some extra speed/code space for instrumenting the code with some defensive bug catchers or field-debug abilities. It is really, really nice to have a bit of extra code that constantly checks important variables for invalid states, out-of-bounds parameters etc and potentially emits a printout, calls a catch-all breakpoint function, ... and then either resets the unit or repairs the parameter to a valid value.

I must admit that I'm not too fond of ICE debugging. I prefer to read code, and possibly add an extra printout to verify an assumption. But it really, really helps if the final product can keep some of the asserts etc. If nothing else, it means that I can get the same timing when debugging and when making a release.

ICE debugging also often requires extra connectors that are not mounted for the mass-produced units, and if visiting a customer on the field, it might sometimes be nice to be able to have a peek inside an installed unit - possibly connected to misbehaving external equipment that isn't available at my office. Black-box testing will only verify test cases I have managed to figure out - but the real world has a tendancy to create a number of semi-impossible situations too.

Having the ability to use spare interface bandwidth to dump memory contents (using CAN, UART, SPI, ...) from a live installation can be a real life-saver, and in some situations it might not even be really safe to connect an ICE. I don't know about too many opto-isolated ICE tools.

An ICE is a valuable tool, but it is one of many, and I prefer - not always a choice I'm in control off :) - to catch my bugs before I need to pick up my ICE. Some people may prefer to pick up the ICE earlier, some later, but it may also be a question about what type of software that is developed. A traditional problem for debuggers is to stop at a breakpoint in a multi-threaded application. What happens with the other threads if they are expected to serve hardware in real-time, and a producer or consumer suddenly doesn't produce/consume data at the speed required by the hardware? An ICE can't stop the PC from sending serial data into the target, and the hardware FIFO can only swallow so many characters before overflowing... With a bit of overcapacity in code size and speed, I may get my information without the breakpoint and without breaking the real-time requirements.

 RE: incapable of writiting

I totally agree!

And, you rightly pointed out the High-Volume 'problem' in optimal hardware design. Making the trade between a $9 CPU and a $12 CPU multiplied by 300,000 units becomes a $900,000 decision. But the 10,000 added service calls you will get also costs money. That is what the managers get paid to decide (BTW I've been there).

Having a debug [kernel] in the code (provided it is allowed) can greatly reduce the field problems, and as you've stated, it is amazing how many "semi-impossible situations" exist. The most cost effective weapon against this is "defensive programming." Defensive programming adds time and code, so the new design must account for that.

The debug capability when "visiting a customer on the field" can be vital for both the customer and your company. Most of the embedded products do are in the realm of low to medium quantity production. The ability to quickly turn one of your "quality based products" with a field error into the operational state can offset the black-eye you got in the first place when it failed. Without the tools to quickly diagnose and repair the problem, that black-eye can cost you not only money but your "quality" reputation.

Mr. Westermark is spot-on when it comes to being capable of quick (and easy) fixes to a system by designing in "overcapacity."

An ICE is preferable over a simulator, but is only NEEDED when you have a serious hardware/software error. The High Volume (>500,000 units) company I worked for did not have an ICE. At first I thought that was funny, but with competent engineers, it is rarely needed... actually we did have an ICE that was super old and lame so it collected dust. It was used once in three years I was there, and it was re-confirmed as "useless". In some cases, you simply cannot find the problem without an ICE. ...Bond-outs!

The over-reliance upon an ICE may inhibit the developer's clarity of thought. Kind of like the Flash versus UV-EPROM code memories did/do/does. When you had only five or ten EPROMS erased, and each erase cycle took four+ hours, you didn't willie-nillie try this-n-that to see if it this modification now works. You had to THINK about it first.

With that in mind, the developer who over-relies upon an ICE might not realize the importance of having the debug capabilities that Per Westermark is advocating. By thinking ICE-less for awhile, you'll learn what kinds of field testing demands there are out there, and how to code-up some really worth-while debugging techniques/services. Like Per said, having an ICE is not always a choice. Using your brain is... keep it sharpened.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 Nothing short of extraordinary !

An awful lot of blurb produced by simple mickey-take!

I don't feel offended that Erik would be preferred at the professional level. He obviously knows how to use an ICE and (apparently) I do not??!!

In general, the comments of Per and Vince are ones I would agree with.

Anyway, WTF - I am a Keil user, have been for many years and still believe that it is the best tool for the '51 developments that I have been involved it.

 RE: Nothing short of extraordinary !

I don't think anyone is contradicting you. Erik is also using the Keil compiler. Most probably because he wants to, and not because he is forced to.

I have currently done a bit of Pic programming, using the Microchip compiler since Keil doesn't support that architecture. The "nice" compiler doesn't even support the full grammar... And at least one construct where it failed to produce a binary - currently unknown if the error is in the compiler or the linker.

We developers do like good tools - it's just that our definition of good (and what kind of tools we prefer) varies with previous experiences and with type of products we develop. A one-man project has different requirements than a 100-man project. A life-sustaining equipment has different requirements than a set-top box. The people developing the set-top box would never manage to finish their product if they had to guarantee the reliability according to the standards needed of a pace-maker.

Because of the different needs, debates about A _or_ B often results in heated debates that doesn't lead to one or he other side switching opinion and most of the time without making any readers switch position either. Debates that focus on comparing two alternatives have a lot better chance to make people listen and try the alternative, since the debate isn't about right or wrong but about how one tool can complement another, or (if the discussion isn't between combatants) leads to information how users of tool A (who can't afford tool B) can find reasonable workarounds to still be productive.

 RE: Nothing short of extraordinary !

Per,

I too have recently used the Microchip C compiler.

The Keil C51 compiler certainly has it's quirks; but compared to the Microchip "nice" compiler and it's quirks, my opinion is that the Keil is more predictable in it's output and therefore preferable.

Now I have had the opportunity to migrate across to the Keil ARM compiler. One comment from me with regards to the compiler - Absolutely lovely!

 so do I

I am a Keil user, have been for many years and still believe that it is the best tool for the '51 developments that I have been involved it.
so do I. But is there anything wrong with wanting 'the best' better.
I have no problems whatsoever with the optimizations provided by Keil (they are optional and I do not use them) I just want another level where some are implemented and the "debuggability killers" are not.

Someone above talked about "debugging by printf". That will work in many cases, but in "my world" where everything hangs on nanoseconds, inserting a time consuming call can make the "debug aid" a bug.

Erik

 RE: Ethics

I do not think that it is ok to put a brochure in a competitors display rack - I find it unethical. Switching over to the electronic world doesn't make a difference.

The reason that HT has posted their advertisement here simply has to do with traffic and volume. The Keil forum has it and the HT forum does not. Even so, I'm not sure that it makes much sense to remove it.

Every few years, another Keil competitor has a "new" compiler release that generates smaller and faster code. At Keil, we welcome this kind of innovation and embrace how it helps to expand and grow the 8051 microcontroller marketplace.

Jon

 RE: will it debug

Erik, I've been following the various threads within this thread with some interest. I wasn't entirely sure what you meant by "uniquely breakpointable" at first, but having done some homework, I now believe that what you are referring to is the problem with some compilers that setting a breakpoint on one line of code may cause the debugger to stop at that breakpoint even though the execution sequence is within a different function or at least section of code.

The major reason why this would happen is that the compiler or linker has performed what is known as "procedural abstraction" or "reverse inlining", i.e. a section of code common to two or more places in the program has been moved aside and replaced with calls to the common code section.

Is that an accurate summary of your concerns?

 RE: will it debug/validate

If I may answer for erik until he does so himself, "Yes." You are on the right track, as that is the most common break-point-able snafu when debugging. Others include an obfuscated method of data store handling (especially passing and returning to and from unctions) is also a concern.

The compiler that you advocate with project-wide "Omniscient Code Generation" is a great and welcomed addition to the optimization processes. But my (our) worry is that the code becomes difficult to track or trace the flow for "debugging" purposes. Much of this thread has to do with the importance of this ability versus the gained benefits of the "tightest-code ever" trade off. Sometimes we are in control of the *need* for it, and sometimes we are not.

My concern is equally shared between development debugging phases, and code validation and qualification phases. The ability to break before a function, load the test-case passed parameters into the appropriate data-stores, and then execute the code unit (function), and finally extract the results is a typical [automated] validation process. This allows the test benches to stress the ranges and conditions of the unit under test and extract the output for post-analysis.

When the break-points and data-stores are not cleanly delineated, the the unit-level testing (or "debug") becomes a bit hectic... and possibly impossible. Even the test-benches need qualification, so having to go through hoops in order to ensure a valid test takes not only time but also extensive and highly tailored documentation; not to mention the explanation to those who are in QA and might not be as savvy to the complexities of the system.

Even if the embedded engineer doesn't do such formal qualification testing methods, the "debugging" process is basically the same as the FQT. You break at a known point (in "C") and track/trace the flow and data through the unit under test (the function or suspected area of error), and figure out why your logic/implementation is wrong.

Typically this is done at the assembly level and not simply at the "C" level since the 'competent' can easily see the "C" level errors quickly. It is our 'advanced' errors in thought that we spend all of our time "debugging" the assembly.

Being able to use a compiler optimization switch to enable/disable such delineation would ease some of these issues. (e.g. Keil's optimization level is selectable, but I'm sure most of the more serious users would prefer the pick-n-choose which types of optimizations take place and not just "Level-9 and all of the levels before it." But we also realize the interdependencies and the overall difficulty in picking and choosing the types of optimizations). Having the OGC do its thing with the caveat that unique entry/exit nodes are to be kept in order to allow break-points would be a good start.

I like the OCG method, but I am concerned over the sacrifice needed in the ease of development in order to eek out a few percentage points of margin on a design.

My personal opinion is that the OCG method will eventually become the new standard for embedded system compilers, and the leading products will have paid a special effort to address the debug, development, and
validation issues.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: will it debug/validate

Even if the embedded engineer doesn't do such formal qualification testing methods, the "debugging" process is basically the same as the FQT. You break at a known point (in "C") and track/trace the flow and data through the unit under test (the function or suspected area of error), and figure out why your logic/implementation is wrong.

Typically this is done at the assembly level and not simply at the "C" level since the 'competent' can easily see the "C" level errors quickly. It is our 'advanced' errors in thought that we spend all of our time "debugging" the assembly.

I'm not sure I have understood this. You appear to be saying that given an error in a 'C' program that is caused by:

a) Faulty logic
or
b) Faulty implementation of correct logic

you might find yourself debugging at assembly level to spot the error?

 RE: will it debug/validate

If you use #define expressions you may get into troubles with multiple increments/decrements that isn't visible when you single-step the C source. You either have to run the pre-processor to get the code expansion, or single-step the assembler code.

C++ also have a bit of magic that can require assembler debugging unless you already "know" where you should put a breakpoint to catch the next step.

 RE: will it debug/validate

Yes. that is what I am saying. Most errors are either faulty logic or the faulty implementation of correct logic... and of course the faulty implementation of fautly logic.

At the "C" level, these can be found 'easily' since your emulator/simulator can show you the logical flow as you single-step through the high-level "C" code, and you watch the data-stores change accordingly. But since the 'hard' problems take a much larger percent of our debugging time, we usually are single-stepping through the underlying assembly code that supports each of the "C" statements in order to find our mistakes. Per Westermark just made a clear and common 'error' that usually is found at the assembly level.

The reason I elaborate on this distinction has to do with the highly-optimized code that causes the underlying assembly language to be seemingly scattered and dis-jointed due to the use of shared code segments and other "odd looking" (but valid) code that the compiler may generate.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: will it debug/validate

Per Westermark just made a clear and common 'error' that usually is found at the assembly level.

I'm not sure that I see that as an example of something that might need to be debugged at assembly level. It's a straightforward 'C' level error caused by a failure to understand either side-effects, macro expansion rules or both. As such I wouldn't expect a competent 'C' programmer to make the error, never mind be unable to spot it at the 'C' level.

I would be interested to see a concrete example of an error that a competent 'C' programmer might make that would not be more easily spotted by reviewing the 'C' code rather than stepping through compiler generated assembly code.

 RE: will it debug/validate

I have to agree with Jack, although I think that making mistakes has little to do with what he considers "competence". When I have trouble with macros I usually look at the preprocessor output, I don't bother to debug them in assembly.

 RE: will it debug/validate

I would be interested to see a concrete example of an error that a competent 'C' programmer might make that would not be more easily spotted by reviewing the 'C' code rather than stepping through compiler generated assembly code.

Here's one. Taken from real life, slightly simplified.

unsigned int i;
unsigned int some_array[12];

...

for(i = 8; i < 12; i++)
{
   some_array[i] = 0xFF;
}

After the loop, some_array[9...11] were found to be unmodified. No other tasks or ISRs are access some_array at the same time. Did you find the error in the C code ?

 RE: will it debug/validate

I got a bit of code written by another developer, and containing a library.

What wasn't obvious whas that the nice guy had decided to create a function-looking #define without the very common curtesy to select all capitals.

Would you suspect the following code to step the pointer twice?

while (*msg) put_data(*msg++);

By your implication, I was incompetent for assuming that the documented "function" actually was a function. Sumething documented as a function should really behave as a function, don't you think?

Since I assumed it to be a function (as the documentation claimed), I saw no need to look at any preprocessor output. However, single-stepping through the code with mixxed assembler/C made it obvious that the function call did not do what I expected, and why the extra increment managed to step past the termination character. If msg had had multiple characters, I might have noticed that only characters at even positions was emitted, but in this case my only character was emitted (as expected), but then followed by a very large number of random junk.

Life is a lot easier when you have written every single line of the code - as soon as someone else have been involved, you have to assume that they have followed the traditional best-practices or you will never manage to get a final product.

 RE: will it debug/validate

By your implication, I was incompetent for assuming that the documented "function" actually was a function.

Not at all.

Sumething documented as a function should really behave as a function, don't you think?

Absolutely.

Life is a lot easier when you have written every single line of the code - as soon as someone else have been involved, you have to assume that they have followed the traditional best-practices or you will never manage to get a final product.

Indeed.

What I was after an example of was something to illustrate the premise I was querying, which was:

You appear to be saying that given an error in a 'C' program that is caused by:

a) Faulty logic
or
b) Faulty implementation of correct logic

you might find yourself debugging at assembly level to spot the error?

To that end I asked for:

I would be interested to see a concrete example of an error that a competent 'C' programmer might make that would not be more easily spotted by reviewing the 'C' code rather than stepping through compiler generated assembly code.

In other words, an algorithmic or logical error rather than one introduced by someone else's mistake.

I'm interested because if there are situations like this, I certainly haven't come across them. If I find a bug when testing I know that the chances that the problem is in my code are high, so I check my code. I can't imagine why I might find it easier in this situation to look at compiler generated assembly rather than the source code I actually wrote.

 RE: will it debug/validate

A lot of debuggers allows you to watch _both_ your C code and assembler, so it does not represent a big disadvantage to look at the assembler.

In my case, it showed where I was guilty of an incorrect assumption. I assumed that the library was written by a competent developer.

But there could also be a situation where I am blind to my own errors, because parts of my brain have already decided that a specific piece of code _must_ be correct. Seeing both assembly + C could then kick my brain out of its incorrect track and have it starting to see what is really there, instead what it assumes is there.

Have you ever looked at a table for your keys, and failed to see them just because your mind have already decided that they can't be there, or that they have to be on the right side of the desk, or that the bright red key ring that is sticking out under a paper just can't be your keys since you know that you haven't touched that paper since the last time you had your keys?

Our brain is a marvel at pattern matching, which is the reason it is hopeless to try to write an application with any real intelligence. But an engine with too good pattern matching has a tendancy to sometimes find patterns where no patterns exists.

I'm a lot beter to stay focused when looking at really advanced algorithms. Most overlooked errors are likely to be in the trival parts of the code - or maybe the debug printout that is left inside the algorithm. If you see 50 lines of non-trivial code, and three debug printouts, you are likely to skip over the debug lines and put all your focus on the "real" code. Such irrational - but not too uncommon - decisions can easily make you miss that little = instead of == in one of the printouts. Or maybe someone have been "optimizing" a bit and added a ++ in the printout, since that saves a line of code - until I come along and decides that the prinouts should be conditionally included...

In the old days, we needed the assembler output since we couldn't trust the compilers. Todays compilers are so reliable that we can limit ourselves to take a peek at the code output for extremely time-critical code, look at compiler output to learn how to use the assembler instructions of a new processor, or now and then just to get our brains to switch track and start to process data again, instead of living on old assumptions.

 RE: will it debug/validate/example

Mr. Sprat, those logic/implementation errors are found in the "C" construct in most of the occurrences... not necessarily most of the 'time.'

You can find ten of those errors in ten minutes but the one that which takes two hours is the type I'm talking about. Hence, most of your 'time' is spent debugging something that is not glaringly obvious that the faulty "C" implementation of faulty logic is in error. Usually the problems that take the most time are those that are a result of 'undocumented features' in the data-sheets, somebody else's code, or self generated. And for those long duration bugs, you'll need to delve into the assembly.

Your request for a logic/implementation flaw that is more easily found at the assembly level was fulfilled by Mr. Westermark's #define type errors. Yes it is possible to deduce it from within the "C" platform, but a quicker approach is to validate the post-processor result of the #define at the assembly level. It was a valid example of your request.

But an example of a 'bug' that is more easily found in the hand tracing level of assembly code is this one (yes, it is an 'undocumented feature' of Keil' optimization settings, but it could be argued that I created it myself too)...

extern u16 Get_ADC_Level( void );

#define MIN_VOLTAGE  (2458)   // 2457.6 = ((FULL_SCALE)/2)+(FULL_SCALE*0.10))

void Intruder_isr( void ) interrupt 0 using 2
{
    u16  val;

    do
    {
        Charge_Pump( );          // should take 10mS/kV

        val = Get_ADC_Vector( ); // lsb = 0.043 kV

    } while( val < MIN_VOLTAGE ); // removed time-out and hi-rel code
                                  // for 'example' clarity
}

The "Get_ADC_Vector( )" function is external and in another module--as you would expect. The compiler (Keil) compiles and links with zero errors/warnings.

By having "Global Register Coloring" enabled in Keil's "Code Optimization" options, the Keil compiler did/does not account for the register bank switch from the "using 2" directive, so the parameter passed back from the function is in error: the compiler generates code that accessed the registers absolutely and tries to place them into the function-return registers.

Keil should have either identified that you must use "Don't use absolute register access" when you use "Global Register Coloring" and you are using the "using" directive in your code, -OR- Keil's optimizer should have properly handled it.

This example of an assembly traced bug didn't take too long because I realized that the 'using' directive does modify the reg-bank and I knew it was a risk point.

But initially I, like any typical user, was relying on Keil to handle that deviation properly: especially since the pre-optimization proved valid. (An OCG would 'see' this cross module error and avoid it)

FYI: My cure was to eliminate the "using" directive since it was clearly not a need. This is because I take the time/overhead to call two functions, from within the ISR, I could obviously afford the time delays of not switching banks. I also un-checked the "Global Register Coloring" since Keil proved that you cannot trust it. Keil's own documentation does not clarify the conflict.

Sprat, the real point I was making is that most of a "competent" embedded engineer's TIME is spent in dealing with "bugs" at the assembly level. The bugs that are cured at the "C" level are the easy "Doh! what a stupid mistake" type while the gotcha's are not as easily found and do require assembly level tracing.

Hopefully the underlying assembly code is not so mangled as to make it hard to trace. (such as register optimization where some needed data-store is held in R3 since the optimizer knows that it can stay there until it is needed, and doesn't have to write it out to the data space just to keep the data-element current. So then you can find the [traced] code comparing against a 'mysterous' R3 that was loaded a long time ago instead of comparing against 'Critical_Threshold' which is what you expected to see).

"find patterns where no patterns exists" == "code hallucinations"

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: will it debug/validate/example

You can find ten of those errors in ten minutes but the one that which takes two hours is the type I'm talking about. Hence, most of your 'time' is spent debugging something that is not glaringly obvious that the faulty "C" implementation of faulty logic is in error. Usually the problems that take the most time are those that are a result of 'undocumented features' in the data-sheets, somebody else's code, or self generated. And for those long duration bugs, you'll need to delve into the assembly

The issue here is that debugging is not pantyhose (one size does NOT fit all). There are individual methods to the sequence ( look at source, check it in the ICE, do a, most likely hopeless, try with a simulator, insert some printf ...) but to find all bugs in a timely manner the most dangerous attitude is "THIS is THE way".

Yes, I do, occasionally resort to looking at the assembler, that is, indeed, a tool in my toolchest and it has, at times helped immensely. Does that make it "the right debugging method", of course not, but neither does it make it "the wrong debugging method".

Erik

 RE: will it debug/validate

If what you are saying is true, then the compiler that translated that fragment of code is broken. Use a different compiler - one that you can trust.

 RE: will it debug/validate

If what you are saying is true, then the compiler that translated that fragment of code is broken.

Why do you think that?

 RE: will it debug/validate

Why do you think that?
Well, apart from anything else, I pasted the code fragment into a C file and compiled it with a few of the variety of compilers I have on hand. All produced code that delivered the expected result. That's empirical confirmation of my assessment by inspection of the code that the description of the observed behaviour was at odds with the behaviour described by the C code itself.

 RE: will it debug/validate

Well, apart from anything else, I pasted the code fragment into a C file and compiled it with a few of the variety of compilers I have on hand. All produced code that delivered the expected result.

Ah, the forum made it look as though you were replying to Per Westermark's post, hence my question. It's a good idea to always quote a bit of the post you're replying to to avoid confusion.

 RE: will it debug/validate

Did you find the error in the C code ?

Given that snippet in isolation I can see no error. Please enlighten me.

 RE: will it debug/validate

Given that snippet in isolation I can see no error. Please enlighten me.

There isn't one (the snippet was all that was necessary to reproduce the error, without any ISRs or multitasking). The programmer made one of two possible errors: Either blindly trusting the compiler to generate correct assembly code, or not religiously sifting through the compilers errata sheets to check for this situation.

Looking at the assembly code, however, it became quite clear that the compiler generated a completely bogus target address for the looping command used in the for-loop, which caused the microcontroller to jump out of the loop after the first iteration.

Not calling any names here, but that was the compiler supplied by the manufacturer of the chip, with no alternative compilers available. When presented with the C code and the corresponding assembly, their tech support commented "We do not think this is a compiler bug.". I've not contacted them again after this. Most of the program was written in assembly, anyway, which was probably a good thing.

 RE: will it debug/validate

Not calling any names here, but that was the compiler supplied by the manufacturer of the chip, [...]

I don't know why I so suddenly start to think about Microchip...

 RE: will it debug/validate

I don't know why I so suddenly start to think about Microchip...

Never worked with any of their products, sorry. But I think there are alternative compilers available for their architectures.

In my case, there was no alternative. And I guess the response from tech support would have been much, much different if I hard worked on a large-volume project (millions of units per year, like ... cellphones) instead of one with a paltry 10k to 100k units per year.

Oh, and nastily enough, the compiler generated completely correct assembly if the debug symbols were turned on (yes, with everything else, including the optimization settings, being unchanged). Took me a while to figure out why I couldn't "reproduce" the error with my debug version, while it was perfectly reproducable with the release version.

 RE: will it debug/validate

The programmer made one of two possible errors: Either blindly trusting the compiler to generate correct assembly code, or not religiously sifting through the compilers errata sheets to check for this situation.

You've missed the point. I was after an example of the sort of error being discussed - a 'C' coding mistake caused by faulty logic or faulty implementation of correct logic. It's a given that one would have to inspect the assembly output if there is in fact no error in the 'C' code.

 RE: will it debug/validate

I was after an example of the sort of error being discussed - a 'C' coding mistake caused by faulty logic or faulty implementation of correct logic.

Well, any case of lawyer code (e.g. use of code with effects not specified by the C language standard) would suffice there. Even the most competent C programmer cannot tell whether the code will do what it is supposed to do without either knowing the implementation details of the compiler or looking at the generated assembly.

(And no, I don't consider knowing by heart what

some_function(++a, ++a);

does on seven different compilers to be part of being a competent C programmer. A competent C programmer will know that this is heavily compiler dependent and avoid such expressions whenever possible. There is no way of knowing whether this will work as intended by just looking at the C code)

 Who would do such a thing?

Regarding the example:

some_function(++a, ++a);

Who really writes code like this? Are the (questionable) optimizations of any side effects from such a line ever worth it?

In our case, all people MUST undergo an intial period of training to ensure that the prescribed development rules are understood before they are let loose at writing code. Hence expressions like the above, and any resultant assumptions are avoided.

Simple.

 RE: Who would do such a thing?

Who really writes code like this?

People who don't know better (and you might have to debug their code at some point), people who don't care and people who are actively malicious.

Are the (questionable) optimizations of any side effects from such a line ever worth it?

Some people may think that writing a program with as few keystrokes as possible is a worthwhile goal.

Granted, the example was blaringly obvious and should make anyone halfway familiar with C cringe. Any compiler with half a brain should emit a warning. However, MS VC++ doesn't seem to care about a = a++; ... other compilers I use do find this worth a warning.

 RE: Who would do such a thing?

"People who don't know better (and you might have to debug their code at some point), people who don't care and people who are actively malicious."

I take your point on that one. I have come across similar dubious practice code in legacy projects.

Not so long ago I was scanning over some code of a (supposedly senior) team member. There was a block of believable code, in a released project, that had a comment just above it stating:

/* THIS CODE DOES NOT WORK */

Not too surprisingly, the team member wasn't part of my team for much longer!

 RE: Who would do such a thing?

Not too surprisingly, the team member wasn't part of my team for much longer!<p>

Well, the question is: If the code (obviously) didn't work, why wasn't this caught during testing ? Or was the comment outdated and the code correct ?

 RE: Who would do such a thing?

No, not simple. Besides assuming that you do manage to teach them all to behave, you also assume that you really are in control of all paths of source code onto your table.

Did you see my example? The library in question wasn't written inhouse, but because of policy reasons (sellers like partnerships, since it looks so nice on the web page...) you sometime have to integrate code you have suddenly got in your knee.

Sometimes management buy products that you may have to take care of. Sometimes your products needs to be integrated with a customers product. Sometimes, someone decides to buy a magic library that will greatly decrease the development time of a new feature. Many ways to get new and strange code inside the house. Not all written by really competent developers.

 RE: will it debug/validate

Well, any case of lawyer code (e.g. use of code with effects not specified by the C language standard) would suffice there.

A competent 'C' programmer wouldn't do that.

What this boils down to for me is this:

If you find yourself reaching for the ICE or stepping through compiler output on a regular basis you are either working with 3rd party junk rather than decent development tools or libraries, or the code you have written is junk. The 'have a go' programmers who 'don't care a hoot' about the standard find themselves unable to get anything to work without constant debugging which they are incapable of doing at source level. Why? Because they cannot tell whether the code they have written *should* work or not. They find out how it *actually* works by experimenting with the compiler, rather than just reading the damn manual.

This is why the world is full of unreliable, unmaintainable junk.

 RE: will it debug/validate

If you find yourself reaching for the ICE or stepping through compiler output on a regular basis you are either working with 3rd party junk rather than decent development tools or libraries, or the code you have written is junk.

I think I have to agree with that. Most code either works on the first run, or reading the code is enough to see what ails it. A bit of guard code can help in case I have made an incorrect assumption about the value range of the input, or in case I'm inserting the new code in already broken code.

 i wholehardely disagree

I think I have to agree with that. Most code either works on the first run, or reading the code is enough to see what ails it
Try, for instance to write an interface to a FTDI vinculum and debug it by the above method, you will die before the program runs.

there are beautiful debugging theories based on all information given is complete and correct just one comment male cow manure.

Erik

 RE: i wholehardely disagree

You are always so poetic.

 RE: will it debug/validate

...unable to get anything to work without constant debugging which they are incapable of doing at source level.

I agree. Among other sins, this approach yields code that is less maintainable and probably less portable.

 confusing the issue

Among other sins, this approach yields code that is less maintainable and probably less portable.
your debugiing method has NOTHING to do with code being "less maintainable". What makes code amongst other things "less maintainable" is 'fixing' bugs instead of removing them.

Erik

 RE: confusing the issue

Erik,
Were you not, at least once in your (presumably) long career, been tempted to win a few nanos here and there by using a platform specific, nasty trick? That's what this is all about. Jack belong to the school of standards and "working by the book". you are the guy that wants to get the work done without loosing a single nanosecond. I do admire your approach, but what I have seen so far persuaded me to join the camp of people who like to hide behind the standard. Maybe it is because I live in the universe of milliseconds critical applications, not less (for now).

 nothing 'nasty'

Were you not, at least once in your (presumably) long career, been tempted to win a few nanos here and there by using a platform specific, nasty trick?
the only "platform specific tricks" I have implemented are 'tricks' specific to the particular derivative I am working with. If a given derivative as far as platform specific has e.g. multiple datapointers and the compiler does not use them, I will, in a time critical application, go straight to assembler. And there I use very platform(derivative) specific trick.

If by platformk specific you refer to the (re the '51)stupid 'portability' (who has ever heard of a 'small embedded" project being 'ported') I confess that if the Keil compiler aloow me to specify DATA I do it.

Erik

 RE: will it debug/validate

Hi Vince, thanks for the reply. I can tell you (hopefully without pushing anyone's buttons :-) that the results I mentioned in the post that started this thread do not depend on any inlining or reverse inlining - i.e. the code IS uniquely breakpointable.

Those optimizations are on the agenda, but they're not dependent on OCG, which is the really new technology that has delivered the improved performance.

The "obfuscated data store" question depends on the capabilities of the debugger (and debug format). The compiler does provide full information as to where variables are stored (which can change between memory and registers) at any given point in the program, but many debuggers and debug formats do not have the capability to make use of this. Elf/Dwarf is AFAIK the most capable format in this regard.

I also appreciate your comments on selectability of optimizations. This is precisely the kind of feedback I was looking for in starting this thread. OCG is a powerful technology, but the final objective is to deliver to engineers what they need - and this thread clearly illustrates that different people have different needs!

Clyde

 RE: will it debug/validate

Hi Clyde,

remember me from the beta days of tha XA compiler?

Those optimizations are on the agenda, but they're not dependent on OCG, which is the really new technology that has delivered the improved performance
to repeat my point ANY optimizations is desirable to SOME, the issue is an extremely flexible 'menu' of which you want to suit YOUR environment.

Erik

 RE: will it debug/validate

Erik, I remember the XA, but not you, I'm afraid. But then I think I've forgotten more than I know, so don't take it personally :-)

 yes

The major reason why this would happen is that the compiler or linker has performed what is known as "procedural abstraction" or "reverse inlining", i.e. a section of code common to two or more places in the program has been moved aside and replaced with calls to the common code section.

Is that an accurate summary of your concerns?