We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello, I was browsing through older posts that deal with the painful issue of portability (http://www.keil.com/forum/docs/thread8109.asp). I was (and still am) a big advocate of programming as much as possible conforming to the C standard, and having a layered structure that allowed "plugging-in" other hardware. But I have come to change my mind recently. I am reading the "ARM system developer's guide" (excellent book by the way. I'm reading it because I want to port some C167 code to an ARM9 environment) in which chapter 5 discusses writing efficient C code for an ARM. The point is, and it is fairly demonstrated, that even common, innocent looking C code can either be efficient of very inefficient on an ARM depending on specific choices made, let alone another processor used! So, if we are talking about squeezing every clock cycle out of a microcontroller - I do not believe that portability without ultimately littering the code is possible!
I'm a little confused. must a discussion about portable code be limited to the embedded processors that Keil supports? not necessarily; however two points: portability is a joke for the small processors and a valid concern for the biggies many participants here discuss the "Keil supported embedded processors" in this forum and other processors elsewhere, thus I would suggest that when a comment goes outside "small embedded" the comment should be so qualified.
we can have a discussion that goes nowhere if someone makes points from the view of "small embedded" and the other from the view of Cray vs a 516 Pentiums in parallel.
This being a Keil forum I would state that in the above the first do not need qualify, but the second should.
Erik
I have naver made any claim based on any Cray machine - just noted that the high-end features of a 25 year old supercomputer are in existence in standard (not even the highest-end) embedded chips. And Keil do claim support for chips with said features.
"many participants here discuss the 'Keil supported embedded processors' in this forum and other processors elsewhere, thus I would suggest that when a comment goes outside 'small embedded' the comment should be so qualified."
So some architectures should not be discussed here even if Keil claims support? Now where is the limit? Nothing fancier than the ARM7TDMI core? What if it is a bigger/faster processor? Does Keil have any "big embedded" forum that should be used?
Keil do claim support for at least dual-issue processors (Cortex-A8 core), and they do claim support for processors with vector instructions. Now, YOU make the definition that this is high-end PC machines or supercomputers or other and not related to this forum ("small embedded"). Please be more specific why you feel that the full range of Keil supported chips do not relate to this debate? And exactly where is the limit where I must specifically mention the exact chip in question?
By the way - the world isn't standing still. If a Freescale or AMD or Intel or IBM chip has a feature that isn't available in any of the currently Keil-supported chips, it is quite likely that NXP, Texas, ST, ... will look into new processor generations with said feature.
Look at the C51 chips. When originally released, they consumed huge number of clock cycles/instruction. If I remember correctly, they even named the individual clock steps since every instruction followed the same sequence even if some clock cycles where NOP cycles. With a bit of improvements to the pipeline, C51 chpis can now issue an instruction/clock cycle.
If you build a surveilance camera today, you more or less expect it to create MPEG video, JPEG or MJPEG stills, perform motion detection and possibly count number of persons passing in the corridor.
Everyone is constantly expecting more. A programmable timer is nice, but a timer controllable by Bluetooth, ZigBee or WLAN is nicer.
Because of this constant technological race, any investment in embedded products requires the developers to look a bit into the future, and think about expansion potentials.
Some hardware will completely disapear. Earlier, people built solutions with a PDA and maybe a data collector connected to a phone. Now the phone has built-in GPS, camera, bar code reader... so the previous hardware product could have been transformed into an application to install in the phone. Such a migration is very much a question of code portability. The application running on "low-end" dedicated hardware suddenly got moved into a generic platform.
I very much think such moves do affect a number of readers of this forum.
Product requirements has a tendancy to move at a quite high speed. "So, you measure the supply voltages 20 times / second. But since you have more AD channels available, can't the product be updated to log 2k measurements/second and store for no more than two hours? But the transfer cost to send in these samples are too high - can't it do fourier analysis locally in real time and just report important changes?"
Or maybe: "But if you can multiplex a couple of LEDs, what does it take to drive this 1k LED panel? But we also have this 30k multi-color LED panel. By the way - is it possible to add an interface to connect TFT panels directly?"
More than once, a product may spin off in a totally unexpected tangent. There is no way I can anticipate such moves, but I can anticipate that there will be moves, and try to make sure that the software investment is as valuable as possible by making sure that as many code blocks as possible can be reused in new projects and/or on new hardware.
All this side track because you posted a bit of buggy pseudo-code with the assumption that bit-and must always win over modulo, or maybe your claim was that bit-and must always win over a compare and optional assign. An assumption that isn't true on PC-class hardware, and need not be true on middle-class embedded processors either.
are we discussing the present or the future?
More than once, a product may spin off in a totally unexpected tangent. There is no way I can anticipate such moves, but I can anticipate that there will be moves, and try to make sure that the software investment is as valuable as possible by making sure that as many code blocks as possible can be reused in new projects and/or on new hardware. again if we are discussing "large" (embedded) the statement is valid, for small embedded it is a joke.
All this side track because you posted a bit of buggy pseudo-code with the assumption that bit-and must always win over modulo I qualify my statements (which you seem to have a problem with) as in "no processor that Keil has tools for will divide as fast as and"
re buggy pseudo-code who cares, it did show what I ment.
Per, let this not turn into a 'war' just realize that there is a world of difference (today) between "small embedded" and large (embedded).
just as an example, this thread started with 'squeezing every bit of performance out of it" which most often is valid in small embedded and rarely (we can argeue whether it should) is applied to large (embedded)
again if we are discussing "large" (embedded) the statement is valid, for small embedded it is a joke.
I work primarily with small embedded and I can assure you that portability is not a joke.
re buggy pseudo-code who cares
Says it all, really.
I work primarily with small embedded and I can assure you that portability is not a joke. portability between WHAT? processors? compilers? houses? a lot of code is "automatically portable" e.g. a mathematical function and for small embedded anything beyond a "computing function" will take more effort to make portable that to port as non-portable.
re buggy pseudo-code who cares Says it all, really. when quoting me, please quote fully
"re buggy pseudo-code who cares, it did show what I ment.
mista mikal,
you is being proudly of tamer is you being yes?????
you be started warrring of erac and jak agin!!!!!!
you be hanging marow on his string for the mans to atack the fight yes????
Kalib, The only thing I see is a well-argumented, intelligent discussion, from which there is a lot to learn. War? I don't think so. Disagreement maybe, but that is the foundation for any progress!
when I say "portability is a joke" I do not say "porting is a joke". My basic reference is that, in the rare instance when needed, porting "non-portable code" takes far less resources than making code portable (most often code that will never be ported). With an intelligent editor (I use CodeWright) I can port a substantial chunk of non-portable code in a few hours, making the code portable would take days.
Wow, amazing how this thread grew. I shouldn't go away for a "3.5-day" 'weekend' (remind me not to get sick again). I point this out because reading what I missed did expose the need to keep all comments 'at the bottom' since all of these posts were 'new' to me... "Given that new posts are highlighted I don't see how that would offer any real benefit"
Ditto to the posts above. (most of them)
ALL embedded code--and an argument can be made for all code--will have non- Porta-Code constructs. Typically the smaller the processor power, the more the PortaCode suffers. Hence, an over-clocked hyper-extreme Octa-Core ubercomputer ALMOST has the luxury of implementing the purest of standardized language programming compliance, while your C compiler for the 1802 COULD take on some contorted coding.
Much of 'it' depends upon your requirements.
Generally what I mean by smaller processor power includes restricted (under-specified might be a better description) resources like program space, data space, MIPS, FLOPS, core-processor capabilities (e.g. no intrinsic 'divide' instruction), and/or requirements that have grown beyond the original design.
But it still goes beyond that. Just because you think you have an under-powered system doesn't mean that it needs to change. A change could spell the doom of the project, so you shall need to squeeze those CPU cycles (period). So much of the real-world applications pressure the software to make up for the deficiencies in system design, mechanical design, and electrical design. Sometimes it is the correct location to apply that pressure and sometimes its not.
The 'doom' of the project could be a simple parts-cost increase that will force your product to cost more, hence won't sell, hence won't need to be made, hence your company folds, and hence you will get the opportunity to find out how 'generous' your company really is.
Or,it can mean that your product now needs to get re-qualified with the 'new' design and that requires far more than can make the project viable, and hence ... (see the hence list above).
Or, this sudden realization that your processor is under-powered could cause you to lose the window of opportunity to have a product:
You are responsible for the new Indy 500 race-car telemetry system, and the re-spin of the board will cause the contract to loose one week and with the help of the team's over-time, the product will be ready exactly 2 business days after race-day. For some reason, the customer will not pay you. Or that Shuttle Launch, or aunt Sally's annual bridge game and her dazzling LED intermission light-show.
In order to determine if the real problem is an under-powered system or something else, you must look at the bigger picture than just the computing power of the CPU and the efficiency of the compiler, but also the other 'intangibles' from a management perspective: unit cost, project cost, maintenance costs, long and short term IP value, and resource costs. Not to mention the other impacts on a system's performance like how long your LiPo battery powered underwater fish tracker will last using software driven floating point 8051 algorithms or that floating point Ti DSP micro.
This is why "Per Westermark", "erik malund" and "Tamir Michael" are 100% right (in all of their posts). You must design your systems with an eye for expansion in both hardware capability and software capability. The most capable software --for expansion/portability/etc-- complies with a standardized language as both the tool vendors and CPU architects know that their products will be implementing a standard language. Stick to it as best you can, but don't fool yourself, you SHALL be deviating from the purest (most portable?) code.
And when you do, you not only have to be smart enough to know it (e.g. knowing that a count-down is quicker than a count-up), but you must be diligent enough to make note of it for when that 'new-guy' takes over the code.
The compiler [and even chip] vendors know that deviations to a standard shall take place, and they try their best to make as many of the non-standardized (and thus non-portable) implementations as logical a possible, and hopefully with minimal impacts (the origion of #pragma comes to mind).
Yes, these vendors want their competitor's customers to easily switch to their tools/chips, so they'll attempt to make it as painless as possible. Sticking as close to a standard helps force the focus onto quality, features, and price... just like you/we should be doing.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
P.S. erik,
WordStar, to Brief (by Underware), to CodeWrite (using Brief Emulation). I've used 'other' editors, but I'm totally hooked on CodeWrite too (alas, only V6.0c though). Its nice to see I'm not the only CodeWrite addict out there.
WordStar, to Brief (by Underware), to CodeWrite (using Brief Emulation). I do believe you mkean CodeWright
there is, I believe, also an editor named CodeWrite.
Doh! Yup. I mkeant "CodeWright." Don't you just hate that?
This is why "Per Westermark", "erik malund" and "Tamir Michael" are 100% right (in all of their posts).
In all of their posts?
Wow, how much higher praise could one person give to others?
The three masters are all totally infullable.
Whoops I, of course, mean infallable.
And don't Jack Sprat, Christoph Franck or the numerous other people warrant a mention of some sort?
1) I am sure Vince referred to this thread only. 2) the fact is that much 'discussion' comes from viewpoint differences
Johnathan, Alright, I am prepared to share some of my glory with you :-)
Of course. And they do it because they are on a mission, or they enjoy embedded programming or feel a responsibility toward younger, less experienced developers. Or maybe it is something else. After all, what is point in knowing if you don't share it? I am sure each and everyone here has a good reason to make his own worthy contributions to this forum. Let's keep up the good work!
My apologies.
I wanted to point out how those people, in particular, were addressing the exact issues I was bleating on about, but they were doing it in a different way that I was.
If you look at the quantity of those three versus others you'll find that 'the others' weren't the heavy hitters here (not that those people aren't heavy hitters, just not on this thread). This forum has some very good regular contributors among the fray of 'students' and the general OMG! Class of participant.
And yes, I was talking about this thread and not their life's work on this forum.