Chipping Away at Coding Challenges

 
 
By Peter Coffee  |  Posted 2004-10-04 Email Print this article Print
 
 
 
 
 
 
 

Processor introductions make significant software statements.

As much as it might seem a purely hardware event, I always think of the autumnal chip-head convocation in San Jose, Calif., as being an important indicator to software developers as well. The hardware models offered to developers, such as RISC and VLIW, define the backfield in the game of crafting productive programming tools. The evolving trade-off of processor capability versus power consumption, meanwhile, sends important signals as to where developers should focus their energies: on servers, on workstations, on personal systems, or on mobile and handheld devices.

The October event has a long history of yielding significant statements from a broad range of makers of both hard chips and soft intellectual property, such as licensable chip core designs. This year continues that tradition with announcements such as the one made on Monday by the United Kingdoms ARM Ltd., which unveiled its "Neon" portfolio of new chips and—importantly—complementary software tools.

Pardon me if I allow my mind to boggle, briefly, at the idea that Neon is aimed primarily at wireless and consumer applications. This is a 64-bit architecture with 128-bit data manipulations—what definitely used to qualify as a supercomputer. The architecture is SIMD (Single Instruction Multiple Data), a form of parallelism thats been well-known to PC software developers at least since the advent of Intels MMX almost eight years ago. With a Pentiums 80-bit floating-point data registers just hanging around, often doing nothing during integer-intensive operations such as graphics processing, Intel had the excellent idea of devising instructions that could work with several shorter data items—eight 8-bit bytes, for example—packed into a single 64-bit "MMX register" carved out of one of those floating-point slots. A single instruction could perform an operation on all eight of those items at once: hence, Single Instruction Multiple Data.

MMX could handle as many as eight 64-bit composite items; Neon can work with as many as sixteen 128-bit items. This progress weakens, still further, the already loosening connection between processor clock rate and actual task throughput: A Neon device, by doing so much work on every instruction cycle, can perform an MP3 audio decode at only 10 MHz.

This brings us to software development, which is what these letters are mostly about. I commented in this space, two weeks ago, that I saw a shifting equilibrium between the lower cost per unit of a minimally tailored software platform—for example, a customized variant of Windows CE—and the lower up-front cost and development time of an all-singing, all-dancing, general-purpose platform such as J2ME (Java 2 Platform, Mobile Edition). I was rebuked, affably but unmistakably, by developers who assured me that in the embedded-device space, "small devices are still the land of hand-crafted code and even operating systems."

One of those developers suggested that "Coffee sees the entire embedded market revolving around cell phones," which of course is not the case; I admit without apology that the newsletter column in question focused on the Internet-client-capable category of devices, this being (I believe) the embedded device class of greatest current interest to readers. Im well aware that the submerged part of the software iceberg is an enormous mass of code thats running, to use one developers example, programmable thermostats and other such devices on chips that are still mostly 8-bit controllers.

But the people Im mainly addressing here, I believe, are doing more complex things on more rapid development cycles, and will therefore be interested in the high-level C-programming support—including a vectorizing compiler—thats part of the Neon portfolio. The Khronos Groups family of OpenMAX media-acceleration APIs will be one of the tool kits available to developers for rapid exploitation of Neons processing power.

I almost never miss the processor conference in San Jose each fall, but this year another commitment on the other coast will be keeping me away: I welcome your e-mail comments on whatever you may see, or perhaps overhear, as the chips fall with the autumn leaves.

Tell me what I missed at peter_coffee@ziffdavis.com.

To read more Peter Coffee, subscribe to eWEEK magazine. Check out eWEEK.coms Application Development Center for the latest news, reviews and analysis in programming environments and developer tools.

Be sure to add our eWEEK.com Application development news feed to your RSS newsreader or My Yahoo page

 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel