One definition of a frame buffer is any buffer that stores the contents of an image using individual pixels. Your prefered usage adds on the distinction that the buffer is used to refresh a raster image.
I do prefer restricting the use of 'frame buffer' to the memory buffer used to refresh the raster display, but there are other instances where the other definition has been used. The Nuon architecture and programming documentation refers to any memory region that is capable of being displayed or manipulated via pixel DMA as being a frame buffer. Part of this reason is that any image has the potential to be a frame buffer - simply set the channel base to the start of the buffer and set the width and height accordingly.
After reading the article, I personally see the whole issue as much ado about nothing. The quotes provided in the article leave me with the impression that those who were involved with the article had little experience with emulators or were quoted out of context. I think this is obvious given remarks like "One of the key breakthroughs is an 'intermediate representation'..." that imply revolutionary thinking when in fact the ideas are not new.
I'm sure their product does whatever they designed it to do, but the article alludes to platform migration and operating system virtualization. This screams out to me that the emulated programs are going to be very well behaved out of necessity, and most hardware interfaces will not be accessable except through API calls. Additionally, desktop PC software and operating environments tend to be much more 'regular' than embedded systems like game consoles. It is much easier to describe the behavior of user-mode code on a platform with a generic memory space and API set than it is to describe the behavior of an embedded multiprocessor system with control registers, DMA, custom graphics and audio subsystems and banked memory.
I also have to question the allegation that "no one has successfully developed an emulator for multiple processors and operating systems." Dynamic recompilation is not new. Intermediate representations are not new. Surely there exist some emulators which are capable of emitting multiple native instruction encodings in the backend. If none exist, I doubt it is because they are not capable of doing so.
Describing a processor architecture and providing an API mapping is not a trivial task by any means. The Transitive tool doesn't just 'simply work,' its requires a massive undertaking to prepare the behavior descriptions that I imagine would be in some ways more difficult than writing an ad-hoc single-platform emulator. I think that calling their tool a "hardware virtualizer" is probably a good idea, but not because its faster than an "emulator," but more because its likely nowhere near as powerful as a system emulator.
Finally, I would also beware the performance claims. Dynamic recompilation is certainly the way to go for ultimate performance, but when you generalize architectures, you often lose the ability to take advantage of native features. Also related to processor capabilities, the overhead incurred by emulation is highly correlated to the disparity between the host platform and the emulated platform. Transmeta processors suffer about 20% overhead and thats using a flexible VLIW architecture designed with x86 emulation in mind and using a dynamic recompiler that supports *only* x86. Thats a huge performance penalty, even if programs are running as fast as needed. Given the generalized emulation approach, I think its clear that the feasibility of such an approach is going to depend heavily on the host platform being more powerful/flexible than the emulated platform.
FWIW, I am the author of Nuance, the Nuon emulator. Nuance currently performs all of the same feats listed in the article including block translation, optimization and 'OS' virtualization (native implementation of the Nuon BIOS). I'm currently working on emitting native code using a custom x86 run-time assembler and backpatch mechanism.
I'm sure its being done as we speak. In 1998, I helped implement a Honeywell 316 emulator to replace a real H316 computer in two F15/F16 diagnostics test stations. The test executive and user programs were all written in H316 assembly language. Seeing that the H316 is no longer in production, the only choice was to emulate the machine given that porting the existing code would have taken an inordinately long time and porting code we don't know about is obviously impossible.
The test stations themselves contain new hardware from the late 1990s and the emulator contains device handlers to communicate to them via GPIB and other busses. The test executive uses standard H316 IN and OUT instructions to access the hardware. I also implemented a TEK400 display emulator and interfaced with a VB app that replaced a big custom console table with dedicated operator buttons that would be used during the tests.
The customer must have liked it because they followed up on the contract with a request for more. In that sense, I'd say emulation is definitely a reasonable option. Its not always the right option. The downside is that there is still have old code to maintain. The system is a little more understood now, but you still have old archaic code. The upside is that writing an emulator often takes significantly less time than the alternative of rewriting.
Slashdot Mirror
One definition of a frame buffer is any buffer that stores the contents of an image using individual pixels. Your prefered usage adds on the distinction that the buffer is used to refresh a raster image. I do prefer restricting the use of 'frame buffer' to the memory buffer used to refresh the raster display, but there are other instances where the other definition has been used. The Nuon architecture and programming documentation refers to any memory region that is capable of being displayed or manipulated via pixel DMA as being a frame buffer. Part of this reason is that any image has the potential to be a frame buffer - simply set the channel base to the start of the buffer and set the width and height accordingly.
After reading the article, I personally see the whole issue as much ado about nothing. The quotes provided in the article leave me with the impression that those who were involved with the article had little experience with emulators or were quoted out of context. I think this is obvious given remarks like "One of the key breakthroughs is an 'intermediate representation'..." that imply revolutionary thinking when in fact the ideas are not new.
I'm sure their product does whatever they designed it to do, but the article alludes to platform migration and operating system virtualization. This screams out to me that the emulated programs are going to be very well behaved out of necessity, and most hardware interfaces will not be accessable except through API calls. Additionally, desktop PC software and operating environments tend to be much more 'regular' than embedded systems like game consoles. It is much easier to describe the behavior of user-mode code on a platform with a generic memory space and API set than it is to describe the behavior of an embedded multiprocessor system with control registers, DMA, custom graphics and audio subsystems and banked memory.
I also have to question the allegation that "no one has successfully developed an emulator for multiple processors and operating systems." Dynamic recompilation is not new. Intermediate representations are not new. Surely there exist some emulators which are capable of emitting multiple native instruction encodings in the backend. If none exist, I doubt it is because they are not capable of doing so.
Describing a processor architecture and providing an API mapping is not a trivial task by any means. The Transitive tool doesn't just 'simply work,' its requires a massive undertaking to prepare the behavior descriptions that I imagine would be in some ways more difficult than writing an ad-hoc single-platform emulator. I think that calling their tool a "hardware virtualizer" is probably a good idea, but not because its faster than an "emulator," but more because its likely nowhere near as powerful as a system emulator.
Finally, I would also beware the performance claims. Dynamic recompilation is certainly the way to go for ultimate performance, but when you generalize architectures, you often lose the ability to take advantage of native features. Also related to processor capabilities, the overhead incurred by emulation is highly correlated to the disparity between the host platform and the emulated platform. Transmeta processors suffer about 20% overhead and thats using a flexible VLIW architecture designed with x86 emulation in mind and using a dynamic recompiler that supports *only* x86. Thats a huge performance penalty, even if programs are running as fast as needed. Given the generalized emulation approach, I think its clear that the feasibility of such an approach is going to depend heavily on the host platform being more powerful/flexible than the emulated platform.
FWIW, I am the author of Nuance, the Nuon emulator. Nuance currently performs all of the same feats listed in the article including block translation, optimization and 'OS' virtualization (native implementation of the Nuon BIOS). I'm currently working on emitting native code using a custom x86 run-time assembler and backpatch mechanism.
"Rosenflanz and colleagues at 3M in Minnesota" One of those colleagues wouldn't happen to be named Guildenstein, would they?
I'm sure its being done as we speak. In 1998, I helped implement a Honeywell 316 emulator to replace a real H316 computer in two F15/F16 diagnostics test stations. The test executive and user programs were all written in H316 assembly language. Seeing that the H316 is no longer in production, the only choice was to emulate the machine given that porting the existing code would have taken an inordinately long time and porting code we don't know about is obviously impossible. The test stations themselves contain new hardware from the late 1990s and the emulator contains device handlers to communicate to them via GPIB and other busses. The test executive uses standard H316 IN and OUT instructions to access the hardware. I also implemented a TEK400 display emulator and interfaced with a VB app that replaced a big custom console table with dedicated operator buttons that would be used during the tests. The customer must have liked it because they followed up on the contract with a request for more. In that sense, I'd say emulation is definitely a reasonable option. Its not always the right option. The downside is that there is still have old code to maintain. The system is a little more understood now, but you still have old archaic code. The upside is that writing an emulator often takes significantly less time than the alternative of rewriting.