Tag: software tools

Virtualization and Linux on a DSP Processor

A small tidbit that I found interesting due to the targeted platform. LinuxDevices reports that the VirtualLogix VLX-NI virtualization layer that used to run only on x86 platforms now also run on TI DSPs in the C64+ series. Basically, you put their virtualization layer on the DSP, and you can then on the same core run both a Linux kernel and a DSP/BIOS kernel. Thus supporting traditional DSP development and Linux-style development on the same core.

Continue reading “Virtualization and Linux on a DSP Processor”

Valve Source Engine Multicore Port (presentation comment)

Game engine development company Valve has a nice presentation up on their website about how they attacked multithreading. It is a nice example of how to solve multicore programming for a particular domain by the classic layered approach.

Continue reading “Valve Source Engine Multicore Port (presentation comment)”

Hardware Debug Support & LinuxLink PodCast

The TimeSys Embedded Linux Podcast (also called LinuxLink Radio) is a nice listen about embedded computing using Linux. Sometimes they are a bit too open-source centric, though, and ignore very good tools that live in the classic commercial world. One such example is the recent episode 20 on debugging tools, where they totally ignore modern high-powered hardware-based debugging.

Continue reading “Hardware Debug Support & LinuxLink PodCast”

FTF Paris: Debug connections threat to secure network devices

In a report from FTF Paris 2007, Info World makes some interesting comments on security and locking-down of mobile devices. Info World » Blog Archive » ‘Flat IP’ mobile networks face new security challenges:

Continue reading “FTF Paris: Debug connections threat to secure network devices”

ARM Cortex-A9, Trango, and Virtualization for Migration

The new version of Trango’s embedded “secure virtualizer” for the ARM Cortex-A9 MPCore is an interesting solution in that it directly applies virtualization technology to the issue of migrating solutions (complete software stacks) from single-core to multicore. The details are a bit sketchy in just how this is done, there is some hardware support in recent ARM architectures, but a little bit of adaptation of a guest OS using paravirtual techniques are likely not a blocker. It also touches on security, implemented using ARM’s trustzone technology. All in all, I think this is a typical example of something that we are going to see much more of.

Power.Org Dev Con: C Domination a Problem for Multicore

I just read a EETimes report from a panel at the Power.org Developers Conference (actually, it is more accurately called the Power Architecture Developers Conference, of PADC), about programming multicore processors for the embedded market. Note that I was not there in person, so I can only take the few quotes in the article and comment on them. The main conclusions are that:

  • C/C++ is going to be the dominant language for embedded for the near future. Nothing really surprising at that.
  • C/C++ being dominant means that parallelism in multicore processors, especially shared-memory systems, will be harder to exploit. That is certainly true.
  • Tool vendors have no good idea about what to do next.
  • You cannot expect to get traction with a new language.

In a sense, blaming the market for not having the good sense to adapt new tools to tackle multicore.

I don’t think things have to be that bleak.

Continue reading “Power.Org Dev Con: C Domination a Problem for Multicore”

Golf Games and Computer Simulations

golf.pngIn my work at Virtutech trying to explain Simics and its simulation philosophy, it is often a struggle to get people to accept that what seems like pretty brutal simplifications of the world actually work quite nicely. Recently, I found a nice analogy in a golf game/simulator. The type where you swing a real club and send a real golf ball through the air.
Continue reading “Golf Games and Computer Simulations”

Comment on Joel Spolsky and Programming to “Moores Law”

Joel Spolsky is always worth a read, and in his post Strategy Letter VI he has a lot of smart things to say about how to consider programming. His basic message is that if you optimize your code too much to work well and fit in the memory of a current machine, by the time that you are done, you find yourself run over by competitors that just assumed machines would be faster and used the same programming time to implement cooler products.

I just have to take issue with this.

Continue reading “Comment on Joel Spolsky and Programming to “Moores Law””