Mac Software On Crusoe? 12
Curtis Diesel asks: "The way I understand the Crusoe processor is that it translates instructions on the fly to its native VLIW Instruction set. It is claimed to be 100% x86 compatible. What about Macintosh? One would think that the conversion to x86 Wouldn't be much more difficult than from Mac's Instructions. Personally, I'd love a Crusoe Web pad running OS X. How about IA-64? Alpha? Maybe even Mips or SH-3? (to run Windows CE or something along those lines) Can I run multiple "code morphing" routines simultaneously? Am I limited to one at a time? Do I need to flash my processor every time I switch, or is the Crusoe just another x86 processor?" Interesting thought. Transmeta has been relatively quiet about Crusoe since the initial release, but it would be interesting to note if it could be tuned to not only emulate x86, but other platforms as well.
Crusoe and Apple (Score:2)
First, Apple is at least rumored to have an investment in Transmeta, which suggests that there may be some work being done on a Transmeta based PowerPC. I would expect that, so long as the Transmeta technology (whatever that means) is not too tied to conversion and emulation of x86 instructions (I can think of a number of things that might be done to speed up x86 emulation that would be of no use for any other architecture), emulating any CPU architecture should be fairly simple.
Second, given that Transmeta is trying to keep the ability to completely revamp the underlying architecture of crusoe, I would be willing to lay a bet that they could design a crusoe that would be able to 'emulate' IA-64 with fair performance, (which shouldn't be too hard, since IA-64 is shaping up to be a real dog). As for the current crusoe design, I would think that it probably lacks sufficient resources (mainly too few registers) to run IA-64 code with any efficiency.
Not on the current chips. (Score:1)
Transmeta is still working on producing and marketing their current chips. Wait and see what happens after that.
Moot point? (Score:1)
Apple is already working on porting Darwin (the Open Source core of Mac OS X) to x86. When they finish that, the Transmeta chips will be able to run it without emulating PPC.
Apple: Public Source [apple.com]
You need more than that... (Score:1)
Basically, youd have to recode parts of the OS and recompile anyway.
VM-WARE not needed (Score:2)
- well the endian-ness would be the biggest problem.
Not necessarily true. I believe that the IA-64 architecture supports switching the endian-ness on the fly (ie can be either). No reason why the Crusoe can't do the same.- The rest would probably be resolvable with a meta- VM-WAREish approach
There would be no need for VM-WAREish software. This is not what the crusoe is all about. There is nothing out of the ordinary about the Crusoe processor (it is a neat, modern, VLIW processor - but nothing wierd). All of Transmeta's patents are to do with the MMU (memory management unit). It has designed to spot when memory addresses do not exist in physical memory - are memory mapped IO any need to be treated differently. The whole point of the Crusoe is that it effectively does VM-WARE's job in hardware.To quote Transmeta's site [crusoe.com]: Transmeta's Code Morphing technology is obviously not limited to x86 implementations.
The code-morphing should be pretty simple - cross compiling from one instruction set to another is generally easy - except when you trip over on the memory mapped IO. It should only become really difficult if the code is doing really fun stuff: self-modifying code, overlaid opcodes, trampolining on the stack, etc.
Should make no difference compiling from PPC rather than x86.
cheers,
G
Re:Moot point? (Score:1)
As for Transmeta chips emulating PPC...like most of the other posters, I think it's a long way off...if it happens. Although it would be cool to switch one's processor from CISC to RISC with a reboot.
Re:You need more than that... (Score:2)
Optional Morphing (Score:1)
It would be possible to add new processor types and instructions, since, that doesn't require a change in the silicon, but a change in the code-morphing software. However, the more different kinds of instruction sets the code has to manage, the slower the system gets. If you only want to have one type of processor instruction set running at a time you experience only the emulation penalty to performance.
Of course, to run MacOS X it would require not only changes to the processor, but also some layer to address various differences in the hardware. Either that, or it would require adjustments made to the kernel and a recompile for that hardware. However, if Apple chose to support Crusoe that would not be a significant difficulty for them.
Each new platform would require changes made to the OS or some type of compatibility layer. While it is possible for individuals to accomplish tasks like that through open source, it would be considerably slower than if manufacturer's were to develop those options. However, in most case it's not worth it for them to put in the effort, seeing as they're not likely to make a significant enough profit right away.
In fact, one has to acknowledge that it may never be worth their while to do so. The Crusoe has yet to be real-world tested on a wide-scale, until then it's impossible to say whether or not it will succeed.
Even if it does turn out to be a significantly better processor than others, that doesn't mean it will be successful. Intel managed to keep AMD shut out on the low-end for a long time, even though the AMD chips were often better performing.
E3 and Doom for Java (Score:1)
Very cool stuff, and I expect that implementing a 68k or G4 code-morpher wouldn't be impossible either. HOWEVER, I don't think tansmeta is looking to much at theat sort of thing right now, until they are sure they have a base somewhere. The Java code-morpher was written as an off-the-clock project by a couple of guys at Transmeta, and is totally not supported by Transmeta.
Missing the point (Score:2)
- Technology: It's a new way of performing emulation; neither entirely hardware-based nor software based it's a blend of both taking advantages of each's strengths.
- Market: It's an end-run around Intel's & everyone else's inability to produce a competitive low-power x86 processor. There are a number of good other low-power CPUs - StongARM, Dragonball, PowerPC, etc. but the x86 has proven to be remarkably difficult to implement in a low-power version.
So this leaves the question: why run MacOS (9 or X) on Crusoe? The point of Crusoe was to provide a low-power version of a traditionially high-power CPU but PowerPC is already a low-power device. Whoosh - there goes the rationial for producing a Crusoe/PowerPC emulator for running MacOS 9/X.So what about just running Mac applications under existing Crusoe/x86 technology? Well, Apple has released & continues to polish it's Darwin project which runs well on x86. As Darwin is the core of MacOS X and runs pretty much as a BSD Unix this would imply to some folks there's potential for running Mac applications directly. The problem comes in when one starts to look at the various types of Mac applications.
- "Classic" Mac applications that run under MacOS prior to X will run under a emulator in MacOS X. This emulator technology is not being released and considering the problematic history of other Mac-under-Unix emulators over the years (remember even Sun sold one) the odds of a good 3rd party one appearing now are low.
- "Carbon" Mac applications are ones that use a cleaned-up subset of the "Classic" API. These require a set of libraries to run that again Apple has not shown any interest in releasing (nor would it be in their commercial interest.)
- MacOS-X-native applications can be in a number of formats ranging from pretty much direct ports of traditionial Unix applications to Java-based to ones utilizing the reengineered OpenStep ("Cocoa") technologies. These are the most likely candidates for running under other OS's or using Crusoe considering their cross-platform roots.
The dfficulties with trying to run the MacOS-X-native applications in other environments will be in direct relationship to their reliance on Apple's propriatiery non-Darwin material like Aqua & Cocoa. Aqua, Apple's new PDF-based interface will be one of Apple's crown-jewels and it'll be neither made availiable to outsiders or easy to clone. Cocoa is in pretty much the same situation - it's part of what made Next so attractive to Apple and provides a powerfull set of tools & technologies that Apple has little interest in seeing move out of their fold. Indeed while OpenStep used to be availiable under x86 this has been discontinued and so far appears that it will live on only as part of MacOS X.So - what do we have? Well, most of the Mac applications out there today aren't going to be runnable practicably. Many of the MacOS-X-native ones will be more portable but will require greater & lesser degrees of porting depending on their Apple-specific technology dependence. For instance the Java-based stuff should move cleanly, things built using Cocoa and requiring Aqua services will be just not worth the effort. Either way there's no particular advantage of running these under Crusoe technology. Indeed one could expect a simpler port and greater efficiency if one just ran them under a PowerPC unix varient at a similiar power consumption as Crusoe.
Re:You need more than that... (Score:1)
Possible in theory... (Score:1)
BTW, my special assignment was about the Crusoe (unfortunately it's only available in swedish, sorry). You can find it at http://skogdoom.n3.net [n3.net].