I tend to be more interested in the generated code for a AVR than I am on a ARM, but I still look at the generated code in both environments. Two reasons: I am interested in seeing new assembly language tricks I wasn't aware of, but I am mainly interested in seeing if I have written a higher level code construct which has been converted into hopelessly inefficient code by the compiler.
I've been aware for a long time of the reports about the quality of code written for a application note to demonstrate a particular embedded environment feature, but the code I was looking at is in the various vendors main software library packages, which is why I assigned the level of trust to it that I did.
I originally came from a DEC environment, so I came from a environment in which I was used to vendors producing very high quality code (and hardware).
As I've moved away from that environment over the last decade, I've come across a much less rigorous approach to code development in many areas, but for some reason I just assumed the embedded vendors main code base could be fully trusted. :-)
Interesting. Even as a embedded hobbyist who is far more developed on the software side of things than the hardware side of things, I find it worthwhile to understand that things like this are possible. Up until now, I would have just assumed (your "a" word again :-)) this kind of knowledge would just be a basic part of any embedded professional's knowledge base.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
And since PCs run our compilers so quickly, you won't lose too much time in the first compilation needed to catch all your typos. ;-)
Copy/Paste always makes sense in some limited areas:
Making sure the function and variable definitions in the header file match the definitions in the C file.
Copying and pasting long variable names from the declaration line to the lines where you use the variables in a calculation.
If a whole function is so useful that you are tempted to copy and paste, perhaps the function should become part of a library. The standard C libraries are a good example of code reuse that doesn't require copy and paste.
Though linked-in library functions can't be got at by the optimizer (I don't think TransMeta has got that far.) I've lately reinvented the .inc file to pull in standard functions via #include. (Was there a standard extension for those files?, other than .h ?)
[8>> OTOH, I like to look at generated code anyway as a matter of
I think the differences in efficiency for any *single* "thing" (statement) you might write are going to fall into the noise floor.
Looking at *how* the code is generated can be educational. But, there is no guarantee that the same set of statements will result in that same bit of code in some other context/application. Sometimes, you make a tiny little change to your source and see
*big* changes in the way the compiler tackles the problem (because it has criteria for each sort of optimization that it
*might* want to apply). E.g., if it can't juggle things in the registers, it might approach a particular code sequence differently because it *knows* that this other approach "wins" in this type of situation. (don't ask me for an example; I have found compilers to be a lot smarter than me for micromanaging these sorts of things! :> )
As far as "assembly language tricks"... A lot of the things the compiler might opt to do can be viewed as obfuscatory IF YOU WERE WRITING ASM LIKE THAT. So, while you might be able to intellectually appreciate the cleverness of such a trick, you might cringe at using it in "real code" because it might cloud one's understanding of that code.
(Horses for courses)
As with anything, a lot depends on the *person* writing the code. Look at these bits of code and ask yourself how they would fare "in your day job". Then rethink that knowing what you have recently observed -- would that be acceptable in your day job?
I think embedded systems have different market pressures on them. Most can't (easily/cheaply/conveniently) be "upgraded" in the field. So, there is pressure to get it (sort-of) right before going out the door. And, it has to be "packaged" *into* a tangible *thing* before it can be "shipped". Often, this means folks play fast-and-loose with the care they take of that code. It doesn't *look* broken (and let's not look to hard lest we discover it actually *is* and have folks breathing down our necks because product is not being shipped)!
Some markets (application domains) have much more disciplined approaches and requirements. Usually, when there is "more at stake" (i.e., safety critical, medical, etc. -- where there is a REAL cost that can be identified and associated with a "failure"... unlike most other markets where the only cost is not directly measurable: "How pissed off will our customers be when they discover this problem? And, what recourse will they have -- besides avoiding our products in the future??")
Of course! More knowledge *usually* is better than less. But, this thread was about finding embedded system developers (or, rather, being UNable to find same). In that context, you consider ways to increase the pool of suitable applicants.
If you are a small firm and have to put *all* your eggs in one "developer-basket", then you would probably prefer to look for more of a "Renaissance Man" instead of someone who just barely qualifies (since you probably can't afford to drag in a consultant when your *one* developer says, "I can *prove* there is nothing wrong with my code -- yet it doesn't run on this hardware. Therefore, I have to assume there is something wrong with the hardware -- but I am clueless to tell you what it might be.")
The best environments I've worked in are those where you have
*really* talented people -- each with their particular areas of expertise -- that are aware of and respectful of the capabilities of other technologies and try to leverage their skills on top of these others. You get far more creative solutions to problems that ultimately manifest as better quality (or more economical) products.
I don't think that is the case with most folks. IMO, the single most important issue is knowledge of the application domain. Not necessarily *intimate* knowledge but a good, working knowledge. If you don't understand what you are trying to do, how it has traditionally been done, the types of things that can go wrong, the types of things that can truly "make a difference", etc. then you're going to produce a lousy product. And, sooner or later, someone will come along who sees all those warts, fixes them and, in the process, takes your market *from* you.
You are correct when thinking like that, but there are other things when looking at the generated code has revealed certain things.
Looking at the generated code for some standard functions made me realise just how bloated some routines like printf() and friends are and made me realise I could do much better than that with things like my own UART library.
Looking at code differences for different sized variables on the AVR made me think strongly about choosing the correct size of variables for certain things as well as making some design choices in various things.
For a current AVR project, I have a tight processor cycle count budget for the amount of time I can spend in a handler and looking at the code while expressing the same thing in different ways helped me choose a more optimum method.
Even though I have not been surprised by anything recently, I still look at the code (with objdump) as a matter of habit even when I am not trying to actively optimise anything.
Tricks was probably the wrong word. I was thinking more along the lines of seeing clever techniques for doing things in a few instructions which I would normally have coded a much longer routine for because "I didn't think of doing it that way". (Although, once again, I have not come across anything new recently, but look out of habit anyway.)
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
On a x86 running in 32-bit mode 8-bit math is just as fast as 32-bit math, but 16-bit math can be a bit slower because those instructions must be prefixed to operate in 16-bit mode.
However if the data set if large enough it might be wise to use small data types because of memory bandwidth. With large data sets memory bandwidth may be very well what is limiting the performance. At least that is my experience with the x86. Also traversing memory in a different way can have significant impact.
Efficient code is not by definition unclear code. However I have seen too often people writing messy code just because they assume it will perform better, without actually measuring to prove they gained anything. Most people are pretty clueless about what goes goes fast and what goes slow (which isn't always obvious with modern processors and memory architectures) and the kind of optimizations the compiler can perform and what not (you have to look at the assembly output once in a while to get a feel for that).
In most cases I have seen the messy code isn't any faster than the straightforward version, and often even slower. Usually it helps more to look at the algorithm than to apply dirty coding tricks, which in end may just obfuscate obvious optimization opportunities.
I've always tried to avoid learning about x86 assembly...
Yes, sometimes cache and memory bandwidth can make a big difference, and outweigh the calculation time differences. When you really want to optimise, especially on bigger systems, profiling is better than guessing!
I agree with you here. Very often, writing clear code means being accurate and specific about exactly what you want, and that gives the compiler the best chance to produce the best quality code. Optimisation "tricks" like changing arrays to pointers, adding extra temporary variables for common expression elimination, etc., mess up your source code and hinder good modern compilers.
That is a real problem these days. Ask if they repair their own cars or Harley-Davidsons. Seriously, that's a darn good indicator. Oh, and ask them whether they can handle a solder iron. If not -> back to 2nd tier. In the same way that people should expect me as an analog dude to be able to plow through some lines of assembler and at least be able to figure out which register gets set there.
That's main problem #2. IME you'll have more luck with older people there.
Proprietary is normal. But younger ones should be able to show some hobby projects or university stuff. If not then that would be suspicious to me. Don't blame older engineers though, I threw away all my Fortran punch cards :-)
It's even worse in hardware, especially analog. Looking for someone who can handle transistor level? Forget it. That's why I have a backlog of work on my desk that stretches all the way into summer.
Very important: Put the job on your web site, I didn't see it there. So people can link to it in emails of the kind "Hey, Joe, did you see this opening?". You are working at a very cool company, and I'd tell them in such emails. That usually gets the attention.
Meantime, send it to me (reply-to email works). I don't know coders in the Bay Area but engineers who might know some. Since you guys have BART and all that I guess it won't matter if someone actually lives in Mountain View or San Jose. Oh, and say Hi to John Larkin :-)
--
Regards, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
I pounce code (and especially comments) at blinding speed with the Wordstar type editor written by my college Edwin van Grinsven in the 80's. It allows me to copying parts of phrases whenever I have code that is similar. It has a copying stack that knows whether things are words, blocks of lines, or rectangular area's. It has macro's that most of the time start from code that is copied from where it already is in the file.
Look at this sample:
\ for M faculty, get factors 5 : get5 0 >R BEGIN 5 / DUP R> + >R DUP 0= UNTIL DROP R> ;
\ for M faculty, get factors 2 : get2 0 >R BEGIN 2 / DUP R> + >R DUP 0= UNTIL DROP R> ;
\ for M over N , get factors 5. : over>5 2DUP - get5 NEGATE >R get5 NEGATE SWAP get5 R> + + ;
\ for M over N , get factors 2. : over>2 2DUP - get2 NEGATE >R get2 NEGATE SWAP get2 R> + + ;
This is cut and paste and ^L ^Z (search and replace).
I have classes in my Forth, but it doesn't make much sense to make a class for two similar subroutines where objects get passed a 2 or 5 constant during creation. But if I did, I would copy and paste the get and over> modules into it. Then I would check if it behaves still the same. Then I would save this version in RCS, (to be able to repeat the test, if necessary, 10 years from now), then I would delete the old get and over> routines outside of the classes.
So, try to take my editor away, and I'll kill you. I'm sure all emacs people will have the same feeling. (And of course I'm using Ediwn's Editor, right now.)
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Yes, that *is* a good indicator IMHO (or ask if they installed their own replacement sliding glass doors :-). And the same way folks should expect me as a digital/firmware guy to be able to use a 'scope to follow some analog signals to end the "finger pointing".
s
.
I'm faced with that very situation now, takes me longer to specify for someone else than to code myself. It's hard to find embedded people these days that can even read a schematic. It seems they all want spoon-feeding, "Where are the drivers?"--well, that's what I need
*you* to do. Here are the data sheets and schematic, deal with it!
Just wanted to thank everyone for their helpful advice on this thread. First of all, we actually put the job up on the website, rather than just on the recruiting pages.
Second, per general recommendation, we stopped even asking for a code sample and instead have written up a coding exercise to test people on. This both gets around the problem of not having any sharable code, puts everyone on a level playing field as far as being able to compare multiple people's solutions, and weeds out the applicants who aren't sufficiently interested to spend an hour problem solving.
We haven't filled the position yet, and have only even lined up one in-person interview, but the process is just going phenomenally better than it has in the past. There's a sense of focus and concreteness that's really been lacking in previous attempts at this, which is good. I'm just a simple engineer, I like to at least feel as if things are quantitative.
So thanks, y'all. It's really greatly appreciated.
-- Rob
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Depending on the size/visibility of your firm, you may want to opt for a *set* of (comparable) "exercises" of which the interviewer selects *one*. This avoids the case where "word gets out" that applicants have to write a piece of code that does XXXXXX. (I've seen applicants show *up* at the interview with this already committed to paper and simply present it to the interviewer... "Yeah, sure... and I know that *you* wrote this, how?")
It's important to keep these simple and sort of obvious so those folks who get nervous in "test" environments don't "choke" when confronted with all these challenges (the interview experience, having to write code while someone is watching them *and* having to think about how to solve a "non-trivial" problem).
Sorting algorithms are great because they are all rather simple and there are enough of them (with subtle variations that you could impose -- e.g., sort increasing vs. decreasing) to avoid the "one standard exercise" syndrome. It also lets you see how applicants use pointers vs. array indices, etc.
And, since they are all reasonably "beaten to death" in the literature, it's easy for the interviewer to be familiar with the various subtleties of each to allow him/her to pose other challenges to the candidate *after* reviewing the code sample.
E.g., "How would you improve on this? In what situations would those improvements be most beneficial? What does this cost as a function of list size? etc."
Actually, my sense of humor is warped enough that I would consider dragging out one of those sets of "pegs and holes" (kindergarten?) and watching the expression on the applicant's face as I held the STOPWATCH (!) and said, "Ready? Go!"
[of course, trying to keep a straight face while doing so would be the real challenge)
As a side note: you may want to keep the results and/or notes from the testing on file, in case someone decides that they didn't get hired because of ethnicity, sexual orientation, gender, perceived gender, perceived ethnicity, etc. Being able to show that you have a test that you can show to be objective, and that you were judging candidates against a stated set of criteria, may help out.
Of course, more than 99.44% of the folks that you decline to hire aren't going to think you discriminated, and of the remaining few, even fewer are going to pursue anything.
But if you save the notes from the testing, you'll at least save yourself some 'tsk'ing from your lawyer if someone does complain.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
The idea of putting up some passive barriers (code a solution for this problem) to applying for the job position is great imo. Only really interested candidates would bother and you might get a glimpse into their ability to code. Facebook has a similar system in place for recruiting engineers. The only drawback is that you might have less, qualified engineers applying if they don't like the looks of the company or work based on your website.
To gain more applicants, I would post at related sites like LinkedIn groups (RTOS, IEEE, TBP, ACM) specific forums, or on high traffic web pages that are related (say a new renewable energy plant opens and it happens to use some of your products or competitors, probably a ton of press releases or news stories with a comments section that could help your exposure) Also make sure your website will attract traffic when engineers are looking for specific types of jobs (good content in your pages)
Over the past few months i've been browsing many different companies career sites and speaking with engineers that work there and or that have worked there. Google has the best PR for recruiting young engineers hands down. Their numerous youtube videos (both PR for recruiting and others like tech talks or similar) are awesome as is most of their career web pages. Perhaps investigate what they are doing right.
To sell your company and the job to potential employees you need to show them how your products and service are cool or meaningful and how your company is better than your competitors (environment, work/life balance, cutting edge products etc.) If you have a really cool product, have a really short video demo of it in action. If your work/ life is awesome, have testimonials from employees that talk about how they love the support that your company provides for them to (compete in triathlons, robotics competitions, do volunteer work, etc) Also, be sure the job description is detailed and accurate. There is no way I would apply to a job at a big company that simply has the job title I like with only a few short sentences mentioning that C programming is desirable. I want to know what I will be working on or what is expected of me.
Then at the same time, keep things short, simple, and sweet. Only show the stuff that really makes an impact to engineers looking around, no fluff.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.