Slashdot Mirror


A Hardware-Software Symbiosis

Roland Piquepaille writes "We all want smaller and faster computers. Of course, this increases the complexity of the work of computer designers. But now, computer scientists from the University of Virginia are coming with a radical new idea which may revolutionize computer design. They've developed Tortola, a virtual interface that enables hardware and software to communicate and to solve problems together. This approach can be applied to get a better performance from a specific system. It also can be used in the areas of security or power consumption. And it soon could be commercialized with the help of IBM and Intel."

18 of 120 comments (clear)

  1. hardware/software communicating? inconceivable! by tuffy · · Score: 3, Informative

    A middle layer between hardware and software sounds a whole lot like an operating system - the sort of thing that "would allow software to adapt to the hardware it's running on". I can't figure out from the article what makes this thing so special.

    --

    Ita erat quando hic adveni.

  2. How about some details? by AKAImBatman · · Score: 2, Interesting
    TFA is amazingly short on details. All it says is:

    ...a middle layer between hardware and software that can translate and communicate between software and hardware, allowing for cooperative problem solving. "This middle layer would allow software to adapt to the hardware it's running on, something engineers have not been able to do in the past," she says.


    That doesn't really say much. In fact, without further details it sounds like dynamic tuning in virtual machines. Which can't be the case here, as that would be reinventing what has already been inventing. (Seriously, her professor wouldn't approve a project like that, would he?)

    Anyone have any more details?
  3. Heh by NeoTerra · · Score: 4, Funny

    "We could use the software to hide flaws in the hardware, which would allow designers to release products sooner because problems could be fixed later," explains Hazelwood.
    Looks like we have a winner!
  4. Re:NoROLAND NOROLAND NOROLAND by bigtangringo · · Score: 2, Insightful

    Why the Roland hate? Many of the stories he submits are valid, interesting stories.

    The stories he submits link directly to the article, it's only his submitter link that goes to his blog. I rarely, if ever, look at who submitted the article.

    If he somehow profits from submitting articles I'm interested in reading, more power to him.

    --
    Yes, I am a smart ass; it's better than the alternative.
  5. Re:HOT! by bigtangringo · · Score: 3, Funny

    Holy hot faculty, Batman!

    Funny thing is she'll probably read this /. thread.

    --
    Yes, I am a smart ass; it's better than the alternative.
  6. Doesn't sound like such a good thing to me by LighterShadeOfBlack · · Score: 3, Insightful

    Hazelwood cites a famous Intel mishap where microprocessors were distributed before a flaw in their fine mathematics function was detected, resulting in a massive recall. A system like Tortola could prevent such expensive glitches in the future. "We could use the software to hide flaws in the hardware, which would allow designers to release products sooner because problems could be fixed later," explains Hazelwood. Oh great. So not only do the public get to be unwitting beta testers for software but we'll soon be able to do it for hardware too.

    I can't wait to pay £400 for a Beta CPU and then get to endure 6 months of crashing until it gets patched.
    --
    Spelling mistakes, grammatical errors, and stupid comments are intentional.
  7. BS again.... by gweihir · · Score: 4, Insightful

    Sorry, but Hardware and software do not solve problems together. That is straight from the "computers are magic"-fraction. Hardware solves problems under software control. Hardware alone can do nothing and software alone cannot run.

    Using inferface layers to get more portable and easier to use interfaces is an old and well-established technique.

    There people are looking for money, right? Why does /. provide free advertizing to them?

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  8. WTF, again?! by vivaoporto · · Score: 4, Interesting

    Although this is not a dupe, it practically is. Check this other story, New Way to Patch Defective Hardware, less than two months old. Basically, both approaches suck in the same way, they allow hardware manufacturers to be sloppy in order to rush the product out as fast as possible while allowing them to try to correct the errors that will appear later in the process. In short, they reinvented the FPGA.

    Two non-stories. But makes one think, cui bono? Who is benefiting from these articles? Roland for sure, being such a click whore. But other than him, who else? Weird, very weird indeed.

  9. Transmeta Crusoe by dduardo · · Score: 2, Interesting

    How is this any different than what Transmeta has already done?

  10. Links and a comment by martyb · · Score: 5, Informative

    Some Links:

    And a comment:

    I'm not entirely thrilled with this idea of dynamically communicating between hardware and software. From what I got from TFA, the hardware would change dynamically based on feedback from the software. It seems to me that we already have plenty of trouble writing programs that work correctly when the hardware does not change... imagine trying to debug a program when the computer hardware is adapting to the changes in your code. (IOW: heisenbugs.)

    Also, I've got some unease when I think about what mal-ware authors could come up with using this technology. Sure, we'll come up with something else to counteract that... but I think it'll bring up another order of magnitude's worth of challenge in this cat and mouse game we already have.

  11. CCS by diablovision · · Score: 4, Insightful

    This article is an example of CCS: "Cute Chick Science". The article has about as much fluff as a popcorn kernel. I am not exactly sure to what they are referring here--FPGAs? There seem to be a number of statements that are overly categorical and seemingly not well informed such as "This middle layer would allow software to adapt to the hardware it's running on, something engineers have not been able to do in the past," and "to engineer software that can communicate between the two layers, [hardware and software]".

    If there wasn't a pic of a cute professor involved, would anyone care?

    --
    120 characters isn't enough to explain it.
  12. Re:NoROLAND NOROLAND NOROLAND by drinkypoo · · Score: 2

    I agree, now, it's not bad. But there's a history there that can't be ignored...

    I read (and commonly vote up) Roland's stories now since he mended his ways. I mean, he did what we were asking, the least we can do is be appreciative.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  13. Re:NoROLAND NOROLAND NOROLAND by tyme · · Score: 2

    Yes, Roland used to spam Slashdot with articles linked to his own web page, which was reason enough to hate him. Thankfully, his posts now link to the actual articles, but that doesn't really help matters all that much. Unfortunately, Roland never seems to understand the point of the articles to which he links. He always writes sesantionalist headlines and summaries that have almost nothing to do with the actual article he references. He picks out specific buzwords from the article, buzwords that excite the most crackpottish centers of the brain, then constructs a boilerplate submission based on those buzwords.

    Is this really a good reason to hate Roland? probably not. It's not like anyone is forcing you to read his drivel, you can always ignore his articles. At least he isn't pushing his own crackpottery with his articles (ala Time Cube or Mentifex). Still, he gets under the skin.

    --
    just a ghost in the machine.
  14. Re:hardware/software communicating? inconceivable! by kebes · · Score: 5, Informative
    The linked article doesn't really explain the work very well. The project homepage has quite a bit more information. What they are trying to accomplish is indeed a middle-layer between applications and hardware (e.g. OS functions or drivers) but the point is the solve a particular optimization problem (speed, low power usage, security) by optimizing software and hardware together.

    So, for example, if low power usage is the goal, then instead of fine-tuning the hardware for low power usage, and then also tuning the software for low power usage (e.g. getting rid of unnecessary loops, checks, etc.), the strategy would be to create specific hooks in the hardware system (accessible via the OS and/or a driver, of course) to allow this fine-tuning. Nowadays we have chips that can regulate themselves so that they don't use excessive power. But it could be even more efficient if the software were able to signal the hardware, for instance differentiating between "I'm just waking up to do a quick, boring check--no need to scale the CPU up to full power" versus "I'm about to start a complex task and would like the CPU ramped up to full power."

    They claim to have some encouraging results. From one of the abstracts:

    We have demonstrated the effectiveness of our approach on the well-known dI/dt problem, where we successfully stabilized the voltage fluctuations of the CPU's power supply by transforming the source code of the executing application using feedback from hardware.
    Obviously the idea of having software and hardware interact is not new (that's what computers do, after all)... but the intent of this project is, apparently, to push much more aggressively into a realm where optimizations are realized by using explicit signaling between hardware and software systems. (Rather than leaving the hardware or OS to guess what hardware state is best suited to the task at hand.)
  15. Roland the Plogger, overdramatizing again by Animats · · Score: 4, Informative

    First off, it's a Roland the Plogger story, so you know it's clueless. Roland the Plogger is just regurgitating a press release.

    Here's an actual paper about the thing. Even that's kind of vague. The general idea, though, seems to be to insert a layer of code-patching middleware between the application and the hardware. The middleware has access to CPU instrumentation info about cache misses, power management activity, and CPU temperature. When it detects that the program is doing things that are causing problems at the CPU level, it tries to tweak the code to make it not do so much bad stuff. See Power Virus in Wikipedia for an explaination of "bad stuff". The paper reports results on a simulated CPU with a simulated test program, not real programs on real hardware.

    Some CPUs now power down sections of the CPU, like the floating point unit, when they haven't been used for a while. A program which uses the FPU periodically, but with intervals longer than the power-off timer, is apparently troublesome, because the thing keeps cycling on and off, causing voltage regulation problems. This technique patches the code to make that stop happening. That's what they've actually done so far.

    Intel's interest seems to be because this was a problem with some Centrino parts. So this is something of a specialized fix. It's a software workaround for some problems with power management.

    It's probably too much software machinery for that problem. On-the-fly patching of code is an iffy proposition. Some code doesn't work well when patched - game code being checked for cheats, DRM code, code being used by multiple CPUs, code being debugged, and Microsoft Vista with its "tilt bits". Making everything compatible with an on the fly patcher would take some work. A profiling tool to detect program sections that have this problem might be more useful.

    It's a reasonable piece of work on an annoying problem in chip design. The real technical paper is titled "Eliminating voltage emergencies via microarchitectural voltage control feedback and dynamic optimization." (International Symposium on Low-Power Electronics and Design, August 2004). If you're really into this, see this paper on detecting the problem during chip design, from the India Institute of Technology in Madras. Intel also funded that work.

    On the thermal front, back in 2000, at the Intel Developer Forum the keynote speaker after Intel's CEO spoke, discussing whether CPUs should be designed for the thermal worst case or for something between the worst case and the average case: "Now, when you design a system, what you typically want to do is make sure the thermal of the system are okay, so even at the most power-hungry application, you will contain -- so the heat of the system will be okay. So this is called thermal design power, the maximum, which is all the way to your right. A lot of people, most people design to that because something like a power virus will cause the system to operate at very, very maximum power. It doesn't do any work, but that's -- you know, occasionally, you could run into that. The other one is, probably a little more reasonable, is you don't have the power virus, but what the most -- the most power consuming application would run, and that's what you put the TDP typical."

    From that talk, you can kind of see how Intel got into this hole. They knew it was a problem, though, so they put in temperature detection to slow down the CPU when it gets too hot. This prevents damage,

    1. Re:Roland the Plogger, overdramatizing again by ukillaSS · · Score: 4, Informative

      There has been a TON of work on creating uniform layers of OS, middleware, that are accessible to both SW and HW.

      * EPFL - Miljan Vuletic's PhD Thesis
      * University of Paderborn's ReconOS
      * University of Kansas's HybridThreads
      * etc. etc.

      This work is becoming very influential in areas of HW/SW co-design, computer architecture, embedded & real-time systems due to it's importance to both research-oriented and commerical computing.

      Additionally, this is now becoming a major thrust for many chip-makers that have now realized that serial programs running on superscalar machines really are getting any faster. Multicore systems are now available, and are still showing no significant speedups due to a lack of proper parallel programming models. In the past, developing HW was considered "hard/difficult" and developing SW was "easy". Additionally, this usually was due to the fact that HW design involved parallel processes, synchronization, communication, etc. while SW involved a serial list of execution steps. Now that we have multiple cores SW developers are realizing that not only do are most programmers horrible at writing code that interacts with hardware (an object of concurrency in most systems), but they are even worse at writing code that interacts with concurrent pieces of SW. The HW/SW boundary is only a small glimpse of how badly parallelism is managed in today's systems - we need to focus on how to describe massive amounts of coarse-grained parallelism in a such a way that one can reason about parallel systems.

  16. Hardware signalling and code re-ordering by skeptictank · · Score: 2, Insightful
    http://www.cs.virginia.edu/~hazelwood/tortola/pape rs/islped04.pdf

    When the hardware detects a problem it signals the software. The software knows the location of the problematic code by checking a "last executed branch" register. A dynamic optimizer(software) then re-orders the code in that region and caches it to be used in future passes through that section.

    The trick will be getting the dynamic optimizer light-weight enough that it doesn't induce performance hits in and of itself. Also, as an above poster noted, re-ordering code on the fly is fraught with peril. It seems this could have application in general purpose laptops, cellphones, and other non-safety critical gadgets. There should definitely be a bit in the machine control register to switch off the optimizer.