Bill Gatliff

• 10.06.2012
• Toward a two-processor world

"Although Android itself is processor agnostic (it already runs in x86, ARM, and MIPS processors), Android apps are not." For certain definitions of "not", anyway. Last I heard, 2/3 of apps in the Google Play application repository had no native code, ergo they would be expected to run correctly on an Android platform regardless of the native instruction set architecture of the host machine. Furthermore, Android is perfectly happy with applications containing multiple runtime libraries, each optimized for a different instruction set architecture. So applications that require native code are not a-priori prevented from being instruction set-agnostic as well.

• 10.06.2012
• Toward a two-processor world

After working two decades in this business, I have encountered only a handful of projects where the underlying instruction set architecture made a difference AND was also being utilized to its fullest. For the overwhelming majority, the peripheral mix of the SoC, power consumption, interrupt latency, and computational throughput were far more important than what flavor of assembly language the processor was speaking. A lot of the resistance to change here is due to the expense of new tools, combined with the testing effort needed to ferret out code that makes unnecessary and/or unintended assumptions about data representation: big-endian to little-endian conversion, suspicious unions, and so on. There isn't a lot one can do about the former, but writing good code (which you should do anyway) fully cures the latter. Come to think of it, writing good code addresses a large part of the tool problem too: despite the fact that I'm a hard-core Linux kernel and device driver author, I need a JTAG adapter about twice a year: to program virgin flash chips. If you routinely need to step code on the hardware, you are doing something wrong. Long story short: you are right that software is motivating the collapse to a two-instruction-set-architecture world: BAD software. Coalescing around one or two ISA winners won't fix that problem.

• 08.15.2011
• Embedded cyber-risks

There is no practical way to assure that an embedded system isn't infected with code that possesses malicious intent. The only long-term solution is to deploy systems with architectures that naturally limit damage when that infection occurs. That means that in addition to being better code monkeys, we embedded developers have to really improve our system design and analysis skills. And our abilities to do failure modes and effects analysis. "The what?", I hear you say. Exactly.

• 02.28.2011
• Can you give me an estimate?

For situations where you need wide ranges AND fine precision, scaled integer arithmetic is the way to go. But then you might be working with 256-bit numbers or larger, something that usually requires a runtime library because I'm not aware of a C compiler that offers something like that as a native type. It sounds onerous, but scaled integer arithmetic can be fast--- faster than floating point many cases. It just isn't as convenient as floating point. Maybe Jack will do an article on arbitrary precision maths with scaled integers at some point (maybe he already has, and I missed it).

• 06.22.2010
• Memory-mapped devices as C++ classes

Hi Miro! One of the motivations for using Dan's approach is that it lets you potentially catch errors in accessing peripheral control registers at compile time. And if you look at the assembly language that comes out of Dan's code, you'll see that it's virtually zero-overhead. Win-win.

• 06.22.2010
• Memory-mapped devices as C++ classes

willc2010: I'm happy to write such an article as a rebuttal to yours. Just let me know when it shows up in print! :)

• 06.27.2010
• The Idiot's Guide to Being an Idiot

The written word is INCREDIBLY important. If you can't write clearly and concisely, how can I assume that you can even THINK clearly and concisely? A person's use of language is an important insight into their thought processes. And a clear thought process is key to good problem-solving ability. And problem-solving is what engineers do! I won't hire an engineer who can't communicate clearly. Period. The only exceptions I'll make are when the candidate can demonstrate to me the desire to develop their communications skills with the same vigor as their other essential skills. Otherwise, I prefer to make them someone else's liability.

• 06.22.2010
• Memory-mapped devices as C++ classes

TsJ: what "silly mistakes" did you spot? We'd love to hear them...

• 06.22.2010
• Memory-mapped devices as C++ classes

Abstracting hardware probably doesn't lead to better testing. Rather, what leads to better testing is making it easy to generate input data sets that exercise as much of your code as possible before it hits actual hardware. You aren't trying to "abstract" the hardware, you are trying to REPLACE it with an object that creates and consumes the same data, but is easier to work with than the actual hardware itself. A subtle but important difference.

• 06.22.2010
• Memory-mapped devices as C++ classes

When you say "stdio", I assume you mean open/close/read/write/ioctl, right? That's a poor model for a timer peripheral, since they neither manufacture nor consume data--- and stdio is all about moving bytes from one place to another in a consistent way.