Slashdot Mirror
Dynamic Cross-Processor Binary Translation
GFD writes: "EETimes has a story about software that dynamically translates the binary of a program targeted for one processor (say x86) to another (say MIPS). Like Transmeta they have incorporated optimization routines and claim that they have improved execution times between one RISC architecture and another by 25%. This may break the hammer lock that established architectures have on the market and open the door for a renaissance in computer architecture."
AFAIK the Linux port of Basilisk II does exactly this with 68k code on x86 and has for quite some time (a year or so maybe more). As to the user who was asking why you would want to do this sort of thing emulators are a perfect example. Basilisk II is a stellar example IMHO, my mid-range PC's run 68k code under Basilisk II much faster than any real 68k mac I've ever seen
Actually, it sounds like what DEC developed for translating legacy binaries from VAX to ALPHA.
Think of it this way: A regular compiler converts source code into object code, this product takes object code for machine A and outputs object code for machine B. It's basicly a compiler that parses object code input.
Normal emulation parses object code and then pretends to be the machine it was written for, this has to done every time you want to run the program. With a translator like this, you translate the object code just once.
Of course, if you have the source, you don't need this, at worst you need a cross compiler.
since the first powermacs, macos has been translating 68k code to ppc code on the fly. also doing some optimization.
So far nobody's sued for patent infringement, and there should be plenty of prior art if anyone does. Of course, that won't stop assholes like TechSearch from harassing people anyway.
A DAG is not the same thing as a tree. Try this for a refresher.
In reality, the compiler produces multiple binary executable files, but they're all contained within an application bundle (or package, I can never keep the terminology straight), which is really a folder containing lots of files, but which appears in the GUI to be a single double-clickable application. Localization can be done this way too; you just include all your text strings in each language, and choose whatever's appropriate based on the user's OS-wide preferences.
And by the way, the old Mac ROM is no longer an issue on Mac OS X, and on classic Mac OS it uses a file on the hard drive instead of querying the actual ROM whenever possible. This was one of the changes made when the original iMac was released.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
To pick up the small shit, obviously. And to deal with systems that predate posix. Autoconf is not, fortunately, smart enough to make porting to Really Stupid systems possible.
Don't bother answering that one, anyone who has written "portable" software knows the Real Answer.
The implication that I haven't is false. The point is valid: the vast majority of non-mainframe vendors (even Apple, finally) are within some fairly small delta of POSIX; for sake of demonstration let's say 1 meter. On the same scale, Microsoft is somewhere near Mars. If they don't want to follow standards, there's no reason to bother developing software for their systems, since they've elected to make it unnecessarily difficult to do so. There's just no excuse for that. Be fucked its developers over and went bankrupt because the developers walked away. No reason the same thing won't happen to our favourite Keeper of Evil.
Let's put this in perspective. People are generally capable of going out and downloading the appropriate binary for their system when presented with a list of options. It's not much of a leap from there to downloading an appropriate compiler for their platform. And typing "make" ain't too tough. Bottom line: Even inexperienced computer users are generally capable of reading and following simple directions.
Sometime around 1995 Apple's macintosh system went from the 680X0 architechture to the RISC base PPC achitecture. Since there were no applications incuding the MacOS itself that was written for this new architecture, at the PCC macs introduction, just about nothing was powerMac native. Despite this annoying problem, most casual software ran faster and the OS fealt far more responsive. Apple manged to do this by re-writting only a few routines in the MacOS. Basicaly they followed the 90/10 rule and re-wrote the most used 10% of the code.
:-). I Still run its decendent to this very day on my old 5200. ) for most powerMac users. Later on Apple included its own version inside the so called PCI PowerMacs and up.
:-)
This gave the first initial boost.
Later the gurus over at Connectix created this program called SpeedDouble which aimed to speed up you Mac by 2x. On power macs, one of the ways this was done was by using a super cool dynamic, re-compiling emulator that would save decoded instructions in a sort of cache and simply execute those instead of going through the emulation process all over again. This product wa smarketed as speeding up your Mac by 2X and while it didn't, the speed increase it offered was still remarkable enough to justify purchasing it (or at least pirtating it
This was the second speed boost.
Over the course of the next few years, Apple embarked on an agressive OS development schedual which, among other things, brought more PPC code to the system. It was funn because the new PPC code would almost always cancel out the fact that the OS was slower because of these new features but if you read the littterature the OS was getting faster with each revision by leaps of bounds. If you follow the posts, Apple's OS should have become self aware sometime around 1999.
The funny things is, to this day, the MacOS stilkl have an absurd amount of 68k code left in it, yet it's faster than MacOS X by leaps and bounds despite the fact that MacOS X is 68k free...
Anyways.. As a memeber of the mac community up until recently, I've heard all sort of promissing emulation technologies. They never work. The best I've ever gotten i real world performance is 1/8 the speed. Forget it. This technology is not worth following. Go visit my web page to see new promissing technology
I thought about something similar. Perhaps it was brought up some months ago when HP started telling people about Dynamo. I was thinking how interesting it could be to apply this as a post-compilation optimization technique. There is every reason to believe that the same techniques can be used to analyze and improve native code performance too.
In fact, this could be an interesting kernel module development project. Allow the Linux kernel to optimize running executables on the fly. Create permanent entries in the filesystem to store optimized binaries and perhaps a running binary diff so that the optimizer could undo something if need be. If enough of the research is in the literature and someone in the audience is frantically searching for a PhD research project...
My opinion is that the whole history of computing has been moving mainframe technology down to the personal computer. Virtual Memory and emulation combined together seamlessly will in time be the norm on personal computers, at least I hope so. The idea is that the user can just click on an old Macintosh application or an old DOS application and automatically boot into the appropriate virtual machine with emulated CPU.
Once upon a time Detroit said that what people wanted was more and more power out of their automobiles. Then the Japanese came up with the astounding brilliant innovation that what people really wanted was reliability and fuel economy. Right now the computer industry more or less says that we need more and more CPU power, but I think they are going to eventually find what consumers want is reliaibility and compatibility. They don't want to be told "Program X will not run on your computer". Instead they will sacrifice a little performance to have something that will be able to run all of their older games and other programs.
there are 3 kinds of people:
* those who can count
there are 3 kinds of people:
* those who can count
* those who can't
OH SORRY.
FX86! or whatever it was that DEC and MS co-developed to run x86 apps on NT on Alpha's running NT
So that's where she got to. She taught me first year CompSci at Tas Uni (Hobart) in 1996. Small world.
Remember that rule about not running attachments, even those sent to you by friends.
Subject: Check out this great program I wrote
Dood, this is leet. Run this.
Attachment: leetapp.exe
P.S. I wrote this in leetspeak first because it was funny, I thought, and Slashdot said the following:
Lameness filter encountered. Post aborted.
Reason: Junk character post.
Maybe this should be cross linked to all those comments about Microsoft adding McHappyLinks to your web site in their browser, or censorship.
Personally I think it's quite reasonable to use 'leetspeak' sarcastically in an attempt at humour, but obviously the autofilters of slashdot don't agree. Bastion of free fucking speach indeed.
You can do this w/ SGI's native compiler. They have a tool called SpeedShop. Using a command like
ssrun -ideal foo
(or something like that: books @ work) and then using another tool with a command like:
prof -feedback_somethin foo.ideal.m1234
where the foo.ideal.m1234 is a file created as the process (w/ pid 1234) ran, you get some feeback file called foo.fdb.
Then, you recompile your app using a switch where you give it the name of the feedback file. Voila! Unfortunately, I only have tried it with a toy executable, and performance actually decreased slight over using -Ofast=ip32_12k and other options. I dunno if gcc has something similar. I certainly don't remember seeing it in any of the documentation.
No, my point was to develop something that
would translate the OS and all other binaries
as a whole. Think of ALL your binaries as one
system. Now binary cross-compile. And yes,
you'd have to identify BIOS calls and do something
equivalent on another system. The reason why I
chose Windows as an example was because it is a
huge mess of cross-dependent code and judging
by its stability, not all the code is cosher.
If your binary-cross-compiler can handle Windows
it can be presumed to be good.
FX!32 we pretty cool. It was made up of 3 basic components: an emulator, a binary translator, and a system call hack.
The emulator was used the first time an x86 program was run. It was pretty dog slow, as most instruction-level emulators are.
The binary translator was used to recompile that binary code into native alpha code, eliminating the emulation overhead. This was done on the fly; chunks of code that were emulated were translated and stored to eliminate the need for further emulation.
Finally, the system calls were trapped and mapped to the native Alpha system calls, meaning you took basically no performance penalty for any windows API calls.
Together, this let you run x86 applications at about 70% of native speed (once you were out of emulation). It worked really well. Unfortunately, those NT Alphas weren't cost effective when compared to their x86 counterparts, except for in some pretty specialized, floating point intensive fields.
You're somewhat correct. I'm really not satisfied with the optimisation matrix they present at that (pr-heavy) site. The only optimisation flag they used was -O. I'd like to see the impact of the runtime-bbt engine on hairier optimised code. I've not dug deeply enough to find out if other information has been released.
:-)
However, this is tangental to the real purpose of Dynamo. It's primarily intended as the second stage of a dynamic instruction translation engine. The fact that they could run native code on it and see performance improvements was a bit of cake.
I think you are wrong. The horsepower costs battery life and THAT is what the consumer wants more of when using a cellphone.
The second reason is that JVM's are not that universal now either in normal computers. Has anyone seen browsers, real games (not tic-tac-toe or equal) or compilers in Java? I don't think that cellphone manufacturers are going to leap ahead of their desktop predecessors. More effective use of things as MIMD, multiple cores etc etc.
I think Java is bloated, just like C++. What we need is better compilers so we can more effectively use the available processing power.
nosig today
They did a really clever thing of identifying long "runs" of code that nobody ever jumped into the middle of, then they treated them as one big instruction with a lot of side effects, and optimized them as a block. (Not one instruction at a time, but the whole mess into the most optimal set of new platform instructions they could.)
...but on machine code!", to match all of the "...but on the web!" patents that have been granted in recent years. Innovation is truly dead.
"Basic-block analysis", which is basically what this is, is a common technique that all good compilers perform on source code or intermediate representations of source code for optimization. This technique has probably been around since the 1960's.
It was quite clever. It's also quite patented, and has been since before the Power PC came out. (And in a sane world those patents would have expired by now, but with patent lengths going the way of copyright...)
The patent application must have read "basic-block analysis
I believe Alphas did something like this. The only real problem is that unless the underlying hardware is very much like that on the software's native platform, the os likely won't boot. To make stuff like this work you'd either have to do the whole motherboard in software (like virtualpc) or sell it as an add-on(orangemicro and apple used to do this), neither solution offers comperable performance to native hardware.
You know a DAG isn't a tree, right?
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I would have though that endianness (sp?) would be one of the easier problems to solve with this approach...
Female Prison Rape in NY
Female Prison Rape in NY
One of the point in this statement stated that this would free us from depending on existing architectures. Sure but this revolution would just put us in the hand of one company instead of the few that are there today. This really doesn't seem like any kind of freedom, does it?
The algorithms which you program a computer with form a general data-dependency DAG. This is what is at issue here. A tree is not sufficient to store this data, nor do the relevant algorithms work on a tree.
They're using a directed acyclic graph representation to to register dependency and scheduling analysis. There are a series of transformations which you can apply to such graphs which correspond to loop unrolling and other optimizations, and you can use this to find faster programs. But I suppose you don't care about things like that. You just want to make fun of a technology you could never develop yourself.
Perl is one of the benchmarks in the SpecInt95 suite. Look it up on www.specbench.org.
*giggle*
The reason it was interesting is because there is so much 370 binary around, either written originally in assembler or created by long dead compilers from long lost source. You young geeks may sneer at this, but wait until you get called at three in the morning by someone in Tokyo asking you to help them debug a utility that you wrote seventeen years and five jobs ago. Don't laugh, it happens.
Anyway, this thing could take 370 binaries and "run" them on a PowerPC. I don't remember the numbers, but it seemed pretty impressive ... something big O average of one 370 instruction to one PowerPC instruction, which is pretty impressive when you realize that 370 is a CISC machine and PowerPC is a RISC machine.
it's more like an old idea come back to haunt us :-) this idea has been around for quite a while (like since the 60s). On the other hand people have been doing this stuff in the mainstream morerecently (the x86 recompilers to Sparc/Alpha, Java JIT, Transmeta etc are all modern examples of this basic idea)
Aren't some Java JIT compilers doing something like this already?
--
May we live long and die out
'nuff said
This is a manual virus. Copy it to your sig and help me spread!
There used to be software that did this for translating x86 software to run on Alpha's. It's not new. The interesting thing about the Alpha product was that it would actually optimize the executable over time to run on the RISC processor. In other words, the first time you would run it, it would run very slowly. But over time as executable was repeatedly anaalyzed it's performance would improve.
Not every computer user, or even every computer user with which I would like to share code with, is a hacker. Let's face it, 95% of all computer owners probably aren't capable of successfully installing a compiler, compiling a non-trivial app, and installing the app. (Needless to say, these are mostly windows users.)
heard of POSIX?
The nice thing about standards is that there are so many to choose from. Yes, the fact that most OSes are now 99% POSIX compatible means that it takes only a day or two to port an app, rather than months. But that's still a day or two per machine, and requires that you own one of every machine. Myself, I've got 6 x86 boxen and nothing with any other kind of CPU. By the way, can we have a show of hands, how many people have actually ported to Windows' "POSIX compliant" API? How many people were slightly put off by their disclaimer "We implement POSIX, but none of the socket calls." Uh, that's really usefull...
"Freedom means freedom for everybody" -- Dick Cheney
Isn't that _exactly_ what FX32 did?
AFAIK it dynamically translated binary
code for Pentium to Alpha processors
with runtime optimazation.
I think it was released in or before 1997.
...Of course, virtually all cell phones are moving towards Java currently. I can't imagine the rest of the embedded industry being very far behind.
ZFS: because love is never having to say fsck
And, you'll note that I *did* address your complaint in my post by noting that source distribution hasn't exactly been a wildly successful means of moving code around, issues with commercial entities not wanting to release source notwithstanding.
Source distribution is a pain in the butt. Making programs is frequently not as simple as it should be, and the ease installing programs under Unix is a very far cry from the ease installing programs under Windows. (And, admittedly, there are a ton of things which are much easier under Unix. But, let's face it, getting programs working is not one of those)
If Unix had a great, working system in place for distributing source which was completely automated, handled missing dependencies gracefully and intelligently, and didn't frequently require you to be a Unix wizard just to get a basic application working, I'd be a lot more inclined to agree.
The fact is, however, that often getting things to work is a hell of a lot tougher and more time-consuming than it should be. Binary distribution is nice and convenient, and until the Unix camp has something in the same convenience ballpark I will continue to maintain that the open-source community has most certainly *not* solved this problem.
ZFS: because love is never having to say fsck
Slashdot admins definitely get more stupid and ignorant every day. This shit is called dynamic recompilation, it exists and is being implemented in both free and commercial projects for *years*. Besides, you have to be really disconnected from reality (and awfully idiot) if EETimes tells you something you didn't know ; that level of ignorance should be punishable by death.
First, they should be using the actual higher level code in the first place since trying to guess what the program is supposed to be doing by looking at the optimized assembly output of a compiler is *ugly* at best.
And even if they can do this, the speedups obtained can only mean that the compiler used for the initial binary version of the program was sub-optimal and should be developed.
So forget trying to turn x86 assembly into whatever-assembly since that's just plain stupid and invest money in compiler optimization.
And if what they say is true, and this is not for the end user but the software house to use and develop, why would someone who has the actual sourcecode for the program spend time porting it to another platform by binary translation? They'd be better off writing some essential routine in assembly for the speedups needed.
What is really needed is an agreed form of bytecode (java???) and good VM's designed for the architecture by the people making it in the first place. If the next athlon/pentium/ppc had being good at JAVA (or whatever VM is best) in mind, then maybe actual full applications could be written for it.
Pedro Côrte-Real.
I'll chime in a little bit. It was used quite a bit in the grpahics world because people would use a verison of lightwave 3D or softimage that ran natively on Alpha chips and then use other stuff that wasn't native to complement those programs like photoshop. Not only did it do runtime optimization and such, but I guess after running something a few times, it would optimize more and more to native alpha stuff so the program would run faster and faster each time it was run.
This Wiki Feeds You TV and Anime - vidwiki.org
What, me worry?
I'm not saying there aren't problems with their solution. I'm just saying that there does exist a specific problem that this is clearly -trying- to solve. :)
"Or am i missing something about the significance?"
Yes: This is not a solution for PCs; it's a solution for embedded systems and telecommunications equipment. Think cellphones.
It is in principle possible for this to work, because most applications are statically compiled, while dynamic binary compilation is free to optimize an application as it runs. GCC might know a lot about processor architecture but it can't know about what tasks you will be asking the compiled application to do, so it can't optimize for that. This is how on-the-fly recompilation can compensate for the overhead of the process itself.
Though the theory is sound, I get the impression that reality rarely matches the expectations of the nerd-geniuses who are charmed by this concept. I have a feeling that Transmeta, for example, thought this technique would deliver them the entire chip market on a platter. Well, what it got them isn't awful, but certainly on the margin and not a competition-killer. And I haven't seen a company staff more densely populated with nerd-geniuses than Transmeta. Anyway, here's to hoping. I sure would love to download this and then try out OSX. Maan, I bet Apple would be pissed if this got big!
I suspect you're right. Because this is no time to shoot for a hyped-up IPO, these guys seem to be shooting at a buyout--and it makes sense. Think about all the chip vendors out there who are getting nervous that their own research on dynamic recompilation is falling behind Transmeta/HP/Compaq. In particular I'm thinking of AMD and Motorolla, but others are possible too.
Ok, boring fact: Java byte code (ei compiled classes) could very easily be regarded as an intermediate representation as there exists no (important) hardware implementation of the JVM.
I believe that the technologies involved in the Dynam(o/ite) projects could speed up Java to the point where it would become a feasible possibility to write Java-only applications.
Regards,
Daniel.
I dunno about you, but I have written an AVL tree in Java, and it ran quite well.
The simple fact of the matter is, even on my P2 400, Java is fast enough for just about everything I need to do. Im sure if I got uppity, I could duplicate all of my most used apps in Java and not notice much in the way of a speed hit.
Yes, it is slow, when compared to C when doing pure number crunching, but im willing to give up a couple of mHz for things like automatic garbage collection, a really slick cross platform GUI toolkit, and built in cross platform networking. And if you really need the speed, use JINI.
Badly written code is badly written code in any language. Dont knock Java without at least giving a bit of consideration to its strengths.
link for the paranoid: http://www.google.com/search?q=cache:6tW1VA1To9w:w ww.fas.harvard.edu/~libcs124/CS/lec3.pdf+directed+ acyclic+graphs&hl=en
You have a point, but it's not as clean-cut as you think it is. What this is going to be useful for immediately is allowing the same OS running on different architectures to run executables from any platform. One might even come up with a virtual cpu to compile into, and then release one homogenized executable which is particularly suited to being translated by "Dynamite".
In other words, translation is going to be easy if everything is done through function calls, and all those function calls exist in the same (or mappable) libraries on the other end. If you're doing things manually, poking at the hardware and such, then things will get rocky, if not impossible. A sparc running linux is very very different from a pc running linux, and that doesn't even approximate the differences between, say, a PC running Win2k, and an Amiga running AmigaDOS. That does not, however, mean this is useless. It does seem to mean that, as you say, it won't result in any 'renaissance'.
--
ALL YOUR KARMA ARE BELONG TO US
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
but frankly if you wanna run binaries on some better achitecture that x86.... recomple them. I should think that slashdot of all places would say that this matters not because only propritary software needs this kind of emulation support. So go ahead run WinME on RISC and crash it in all it's buggy bliss on another chipset. If the other posts didn't get this point through then here it is...
OPEN SOURCE MAY NOT BE FOR EVERYONE BUT EMULATERS ARE ONLY USED BY THOSE WHO USE OPEN SOURCE, AND WE ALREADY HAVE OUR FILL.
you can just feel the negative karma
#set prompt = $user.$group @ `hostname -s`#
root.wheel @ reality#
Remove *your pants* to send me email.
Wow! If they can, I'd just keep on translating the programs back and forth and after a while, they'd start running before I told them to. One step better than quantum computing!
--
The lack of support from anyone aside from DEC was what killed Alpha NT, and the price. Oh, yah and Linux's much greater functionality/cost ratio.
I assume it's primary use are applications, and applications in every OS that somehow deserve this name don't have to do any I/O themselves. They just call open(), read(), write(), ... and the OS does the real I/O. So the only thing that would come near your idea, would be translating different calling mechanisms for OS-calls, which should be rather straightforward.
... maybe it's crazy enough that someone would try ... wait, Transmeta allready did that :-)
I think running a whole OS on this technology would be crazy
Musta worked well. You see Alphas running NT all over the place.
I recall AMD doing a deal with Transmeta, but I forgot where I read it.
Cool. An infinite speed computer! Run an emulator on an emulator on the processor and you've already seen 44% increase. Do that a few more times and you're set.
I would have to concur with other slashdotters on this one: Who the hell cares about binary translation? So they made it a little less slow... who cares? It's still slow and if you can't compile for the target cpu, you probably have bigger issues (such as screwed up licensing, stupid developers, or BOTH).
And what about OS issues? Surely you can't run binaries meant for one CPU A on OS A, using CPU B and OS B. Even if CPU B emulates CPU A. So fine, you say. Just install OS A compiled for CPU A on CPU B and be happy. But at that point.. why not just call the whole thing off? Buy god-damn CPU A and be done with it. Really.. hardware is dirt cheap these days and emulating other CPU's on one CPU doesn't seem as great as it used to seem maybe 10--even 5--years ago.
You are making your little fantasy land of just sending your windoze-bound family members binaries you were running on a sparc sound really credible. However, you are mistaken. Just having a binary that can run on your machine but was compiled for a different OS is NOT going to help you much when moving from sparc/solaris to windows. Case in point: take an intel solaris binary and try running it on the SAME dual-booted machine which booted into win98.
You can't do it.
In fact, I challenge you to even try running binaries compiled with different versions of glibc on the same cpu/kernel combination. Chances are even then you can get a segfault.
Frankly, I really don't know WHAT problems translating CPU's solve. They are yet another marketing gimmick.. and I am afraid of the possibility that one day manufacturers will adopt this technology as a cheap alternative to the real thing. Namely, they build some overly simple CPU and then have it emulate a Pentium, IV, let's say, and try and sell it to us. Half the time our apps won't run too much slower, but sometimes they will. Actually this isn't a bad thing.. it will probably mean we can get cheaper laptops if we want to go with the cheap-plastic-replacement of a CPU.
using various optimization levels,
Errm. It only sped up SOME of the binaries. In other words, if you DON'T optimize it in the compiler, the 'translator' can do post-optimization.
And the speed-up is a breakthrough???
So it's just a new compiler - it's just that the source is binary code, and it doesn't have the optimizations turned off.
Nothing implies that it's really effective as profile based optimizer
For that matter, consider some of the software that was written for the Alpha - There was a compiler that used VAX assembly source and produced Alpha binaries - and don't forget the FX32 intel translation.
Liquor
Liquor
Sanity is a highly overrated commodity.
Here are a couple links to the now dead FX!32.
--
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
IIRC the system would perform a nightly optimization pass on translated x86 binaries.
No it means architecture specific optimizations dont port 1:1 (DUH) and that their compilers still cant optimize DSP code as well as a human... of course the compiler doesnt have that much to work with, a on the fly reverse compiled binary is not exactly the best input for a compiler.
By the looks of it this works exactly as Transmeta, most of the time run binary translated code sometimes revert to emulation (for instance for run-time optimization/running uncommon code/perhaps running code for the first time etc etc).
This _doesn't_ free you from dependence on an OS, which is the real problem. The only thing I can see it being useful for is taking someone else's compiled program and translating it. If you have the source, you can just recompile.
The only problem there is that the license probably prevents. While it would be neat if this could be used to make, say, windows, run on new processor X, even if it was technically feasible, this probably counts as dissasembly/modification and therefore is not allowed by the EULA.
You sound awfully foolish. Just because it hasn't yet been done doesn't mean it can't. Believe me when I say that I am skeptical as well, but it is not so far-fetched that it is impossible. As long as there is human ambition involved, the sky's the limit.
To use the examples from the post directly, this makes bringing Linux programs from your (x86) desktop to your (MIPS) Agenda even more trivial. This device just became even cooler!
From hell's heart I fstab at /dev/hdc
I remember a shareware DOS program that pretended to do exactly that.
Are you really stupid, or do you have no sense of humor? Anyone with half a brain can see that the post was a JOKE.
God must forbid it! This is all a conspiricy of BillyBoy, don't say i ain't told you so!
Come on people, this is BS. it's a bloody IPO, they're just out there for the publicity...
This sig is intentionally left blank
Well I think when you're given that answer, it'd be safe to say they've got an x86 computer... I'll give ya 3 guesses as to which operating system they're running also ; )
-C
"Well kids, you tried your best, and you failed. The lesson is, never try." -Homer Simpson
"And i could lead into the slashdot mantra of if all programs were opensource, we wouldn't need somethng as sloppy as an emulator anyhow... "
So the user just obtains development tools and recomplies the program for their system. OS issues aside, this is not a good solution for most users. Let the vendor do the cross-compiling, that's what we pay them for.
What about Generalissimo Francisco Franco?
yeah,and it was closed source for how many
years? i doubt it uses an assembly in the
source, which would make it non-portable.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
There was a program that I never could get to work properly, that attached itself as a debugger to Linux applications under Windows 2000 and allowed them to run by intercepting and translating the Linux system calls into something Windows 2000 could handle, and translating the responses. I tried to use it on a information tap on my LAN, to syphon cheat info about a game out of the packet stream between the system I play on and the one that served the internet connection, but it didn't quite work that way, and I ended up deleting the program. Does anyone know where I can find something like it again?
http://www.gbstation.com/ubb/Forum1/HTML/001436.ht ml
"Watch these suckers jump when I get root." - l33t j03
cd /usr/ports/[category]/[app name] && make install
Moderators, I will save you some time reading this diatribe - this is flamebait.
Every time Slashdot announces something neato, a goodly amount of the readership poo-poos it. This is annoying by itself, but what I really dislike is the way such comments are moderated. I browse at 5, yet I still have to wade through the sour grapes and inflated egos.
It is easy to look down on an accomplishment that you didn't achieve. It seems to be hard to add useful content (some of you do a good job, though). Moderation trends perpetuate the problem.
Here are a couple of suggestions for good moderating:
Now we don't have to use Linux of cross platform support now we can cross compile windows!!!
Since Mac OS X only supports Apple branded PPC hardware currently, these features are somewhat wasted. I personally would love to see Apple support other types of hardware (SPARC, MIPS, Alpha, PA-RISC, IA-64, and even x86), but I'm not holding my breath. It appears that (for now) Apple is using Mac OS X to sell PPC hardware (which I like much better than x86). Until that changes, I wouldn't expect to see support for competing hardware (IA-64 or x86). Porting to any other architectures (i.e. SPARC) probably wouldn't generate enough cash to justify the effort.
I do believe that it would be possible to run Mac OS X on other PPC machines however. Since Darwin is open sourced, the kernel could be ported to say an AS/400 or a PReP/PPCP workstation and since Mac OS X is binary compatible, it would probably be possible to run it.
As for non-PPC hardware, I've been thinking that if you managed to get Darwin ported to SPARC (or any other instruction-set), it might be possible to combine it with an emulator or a "Dynamic Cross-Processor Binary Translator" to be able to run the rest of Mac OS X and other PPC software written for it (i.e. Photoshop). It may be even possible to store that translated code to "fat-binary" mach-o files for native execution at a later date.
Once the whole environment was working, gcc could be used to compile applications (when source is available or developers willing) to natively support that hardware. Since Mac OS X uses dynamic linking, it may even be possible to mix and match native and emulated code in a single application (PPC application, SPARC pluggins).
Something like this would take an enormous amount of effort though. It's probably a lot easier to just go out and buy the latest and greatest from Apple, which is pretty competitive with the other workstation hardware in it's price range.
So does each different pair of processors have a different release? say intel -> ppc or sun -> amiga?
And does this mean, perhaps, if we get this software running nicely in a chunk-o-firmware, we can have amp? (as opposed to SMP)?
Just curious...
-- "It's tough to run with both feet stuck in your mouth" - Zoe's evil side
Gotos can be used to create cycles.
So DAGs cannot imply gotos. (acyclic, see)
Back to school sonny.
THL.
--
Keeping
I've been told by a LinuxPPC friend of mine that you can run Mac applications natively on LinuxPPC (I'm not sure how true this is, I don't use Macs too often).
If this is the case it should be trivial to translate Mac applications (since most major applications are already translated regularly to the Mac platform) to x86 architecture and then run them in Linux x86.
This would result in a huge wealth of user applications being available to the Linux Desktop (the reports of who's demise have been greatly exaggerated).
Just a thought, of course I could be totally misinformed.
I would rather be ashes than dust!
It was even cooler than that; the 68k emu used 68k toolbox calls which it would, of course, interpret for itself. it was a recursive emulator.
big deal. Apple did this years ago with their DR emulator; it translated 68k to ppc on the fly, and is still in use today on every powermac! It'll execute 68k code faster than real 68k boxes.
The equivalent technology was the core of MAE, the Mac Application Environment for Solaris and HP-UX(?).
Bell Labs did a static version with its flashport stuff, which apparently is gone. It translated 68k assembly/binaries to powerpc binaries.
Sounds like the only difference is you can retarget the back & front ends, a la MAME.
Seems like this should be pretty simple for code that is already 100% portable.
Can it do more than this?
--Dan
*sigh* back to work...
Three Dead Trolls in a Baggie said it best. Every OS sucks. Download that song right now, it's hilarious.
I think you've confused two separate issues:
Renaissance in computing? I don't think so.
Equate this new development with WINE. WINE can run some windows software on unix, so that people don't have to switch. By this logic, WINE would have ushered in a new era in computing.
But it didn't, and this new binary compatibility scheme won't either. Bugs, incompatibilities, inconsistencies, etc on the ported platform will always give the native platform an advantage.
Besides, it is doubtful that software companies will provide support for other ported platforms, further reducing motivation to use this binary compatibility.
I wonder how long it'll be before we see a Java:x86 port.
Oh... wait...
directed acyclic graphs = GoTO
Let's say my source architecture uses interrupt-based I/O. My target uses memory-mapped. Will this translator be able to handle that?
Non Sequiter argument. You can have interrupt based memory mapped I/O (ask any PPC developer!).
I assume you meant to say port-mapped vs. memory-mapped.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
A lot of people have pointed out this is nothing new. But that's a good thing. It makes it slightly less probable that the USPTO will issue them a patent. (Maybe. If someone challenges it. And has enough money to pursue the case.)
Tandem did this years ago. Their first machines (some time in the 1970s) were CISC. In the early 1990s they changed the hardware architecture and changes the CPUs to RISC. Code compiled for the same version of the OS on a CISC would run interpreted if the machine it was running on had RISC CPUs. Granted, native compiled RISC code ran faster, and it wasn't binary-compatible across major version changes of the OS. But it is basically the same.
Frankly, I must disagree with you -- Debian *does* have mechanisms for automated source (as well as binary) distribution, completed with dependancy handling and the like.
Indeed, apt-get has wowed a great many of my (formerly) Windows-using friends. No installers needed! No library conflicts! etc...
If by "Unix" having a "great, working system" you mean all major unices having such a system, you're quite right that they don't. However, there are some excellent solutions in place.
(I'll grant you that this is *not* true for everything else the poster mentioned -- Java,
There is more information content in the original code for an optimizer to make use of then there is in a binary (or assembly). If this were not the case, would not optimizers run *after* the assembly translation is done? In fact, all reasonable compilers run the vast majority of their optimizations *before* the translation occurs, and only a few small peephole optimizations are done on translated or nearly-translated code. The unfortunate (for them) facts are that:
The verdict: don't fall for this. Even if it works, and even if it has no effect on performance in the common case, there's no benefit. The only useful things that can come of this are the magic peephole optimizations they might be using, which should go into general-purpose compilers.
"directed acyclic graph", abbreviated "DAG", is a generic term describing a data structure. You might also call it a "tree". That their internal data is stored in such a structure is almost implied by the nature of the software. That is how compilers generally store their internal data.
That's what this is: a compiler. Its input is a machine language instead of a high level language. This is interesting, but not necessarily all that useful. It solves a piece of the problem, but not the hardest piece.
The ability to take an existing piece of code and run a static optimizer on it might be interesting, but I suspect that such a device would exercise enough previously undiscovered bugs in the targeted software to make its use as anything but a testing & debugging tool rather impractical.
The idea you suggest resurfaces every few years. A while back it was called "thin binaries"; in the late nineties it was called "Java". In any case, it never takes off quite as well as everyone seems to think it should, simply because the processor is only one part of the machine, and not the hardest one to emulate.
-Mars
Well... yes. But I didn't want to spend half an hour discussing the issue. How would *you* have explained it?
-Mars
It used dynamic recompilation of the sort mentioned here, and from what I've heard, was at a pretty acceptable speed. It also did run-time optimization, or as Transmeta would put it, code morphing.
I believe there was also a FX!32 compatability layer for Digital Unix and later Linux, although support was slightly more sketchy. If I remember correctly, this was around the time that Digital made it possible to use libraries compiled for Digital Unix under a Linux environment.
Anyone else have more to say about FX!32? I'd be interested in more info.
Dynamo dynamically optimizes binaries; an equivalent in the Java world is IBM's Jalapeno VM. Unfortunately, the Dynamo approach is only feasible on the HP architecture, because the PA-RISC chip has an absurdly large i-cache (extremely aggressive in branch prediction.
I think bochs is great as it allow intel binaries to run on all sort of other platforms. You just need a super fast PC to get some performance out of it..
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
The comment that this is not suitable for
hand-optimized loops in DSPs plainly
means that this is an emulator.
What would be cool instead is if someone
made a binary cross-compiler so it would go
through you harddisk's binaries and convert
them from, say, x86 to PPC so that you could
take your hard drive, take it from an x86
system, put it on a Mac and have Windows
boot natively (modulo ROM issues on Macs).
All without access to Windows source code.
For certain classes of problems, compilers do a hell of a lot better job than people do. I don't think most people are that great at optimizing assembly code by doing things like properly sharing registers. In general, when it comes to optimizing memory access, compilers will beat 99% of all programmers out there.
But for picking a better algorithm, no, compilers suck. But I don't know of any active research in having a compiler change the algorithm implemented by the programmer, so you're using a straw man here. Then again, it's been 4 years since I've done any compiler research...
-jon
Remember Amalek.
How about footprint? From the article it sounds like this emulation will require a couple of MB.
I'm in no way an embedded expert, but I was of the impression that RAM is expensive in the embedded and small form-factor world.
I can see that this technology might be a time-to-market saver if you have a load of assembler written for one embedded CPU and want to move it quickly to a new platform.
Hmm, how about the interface with support and I/O chips? This thing is, from what I understand, only a cpu emulator/translator. If you change the platform you will probably have to write new drivers for the other chips.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
I wonder if the specs for DAG will be open so that code can be compiled directly to it, optimized, and then distributed, saving the first two steps in the process. I can see commercial software vendors being all over this idea.
Target CPU neutral binary formats have been around for a while. OSF has ANDF (Architecture-Neutral Distribution Format). Also check SDE (Semantic Dictionary Encoding).
A hardware neutral distribution format is not the complete solution, though. The target platform that you want to run the executable on has to provide the software environment and APIs that the executable needs.
So, it is only suitable for distributing CPU-neutral but OS/environment-dependent user-space applications. What it really does is to save you the job of recompiling an application for PPC/x86/SPARC/whatever-Linux. This would certainly make life easier for non-x86 Linux users, but it is not a general solution for making applications platform-independent.
If you want a run-anywhere solution you also need to define a runtime environment, which is exactly what Java does.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
Why not recompile it natively?
Ah, that is the question.
Some believe that dynamic optimization can do things that static optimization can't do. For instance, you can straighten code that used to have a lot of branches in it. You can't do that statically because you don't know which branches will be taken most often. You could do every possible straightening and include them all with the binary, but that would probably be prohibitively large. You could profile the code and use that to direct a recompilation, but then that's nothing more than really-slow dynamic compilation.
So, once dynamic optimization technology has advanced, it may outperform statically-optimized code even in the same architecture.
Now, what happens if you dynamically optimize the dynamic optimizer...
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
The solution is source distribution.
Compilers know more about the program than translators do, and they also allow linking to native libraries. Can a translator do that?
Yet another proprietary solution to fix another problem caused by proprietary solutions.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Mike Van Emmerik is still working on the project, as is 4 students. The project leader Cristina Cifuentes is currently doing research at Sun Labs on commercial extensions of this work. There will be an open source project at the end of the year apparently, the code has already been released under a BSD style license but it is not publically available as yet. The funding from Sun was a gift to Dr Cifuentes simply because they liked what she was doing. I was just a happy employee when I wrote that broken backend.
How we know is more important than what we know.
Uhh... Are you a troll, or are you just really stupid? Have you actually TRIED gzipping a file more than once?
Original Tar file: 30720 bytes
Gzipped tar file: 6895 bytes
Gzipped gzipped tar file: 6923 bytes
Basically, you get ONE chance to properly discover all of the redundant data. After that, it's pretty much an uphill battle.
I'm not sure if EEtimes is oversimplifying, or if Transitive technologies is filling heads with BS.
"...Translation, sometimes called software emulation..."
Translation != emulation
"...Crusoe specifically takes X86 code...In contrast, Transitive's...[fluffy adjectivies]...can, in theory, be tailored for many processor pairs.."
Crusoe isn't X86 specific, and it can be tailored for many processor pairs in reality, not just in theory.
"...We have seen accelerations of code of 25 percent..." doesn't mean that everything runs 25% faster. I don't even hear Transitive technologies saying that it does.
I wonder how many more companies will come up with new and innovative techniques like this now that Transmeta has become very noticable? I wonder how long before the cash-strapped Transmeta starts filing patent infringement suits? (Please Linus, make them play fair!)
I completely agree about the dynamic content bit -- and I don't think the right answer is for us to have to mail around tarballs of C source and makefiles.
And while you're correct in spirit, in that converting from Java byte codes to native code is fundamentally the same problem as converting from native Platform A code to native Platform B code, the latter is orders of magnitude more difficult. Java was designed for just such a conversion, and so is about as simple as you can get.
Real Programs, on the other hand, are unbelievably complex to the point that simply deciding "Is this byte code or data (or both)?" is literally unsolvable in the general case. For comparison, the distinction between code and data is obvious in Java. Plus, for "real" emulation you have to emulate all the weird I/O ports and other basic hardware, none of which is trivial.
Comparing a Java VM to serious hardware emulation because they are both emulators is is like comparing "Hello World" to MacBeth because they are both English text -- technically correct, but not a really meaningful comparison.
ZFS: because love is never having to say fsck
Now if they could figure out a way to deal with endianness, and the other 99% of the platform specific stuff in most code, it might be worth something...
http://www.masturbateforpeace.com/
VMWare isn't an emulator.
If you're thinking in terms of desktop systems and software written in high-level languages, you're right. But the target market of this company is the embedded systems world, where the code is typically hand-optimized assembly and even custom-made instruction sets for systems that are built from heterogeneous proprietary systems. Some proprietary chips are better than others, and often you don't know which is the best solution until you've already implemented the whole thing.
For the telecom industry, this solution, if it works, is a very good one.
If you say otherwise, you're ignoring history. RISC processors rock for most application. Look at Transmeta, a 700 MHz Crusoe can act as, worst case, 300 MHz Pentium III, using a lot fewer transistors and a lot less power. If MP actually worked, you could get such an advantage based on silicon space of performance/power.
Opinions?
At the beginning was at.
The more deeply the optimiser is run the BIGGER the percentage speedup Dynamo gives. The reason is that the speedups are different speedups than the ones found by the compiler, and the less time spent in the rest of the code, the more significant the speedups are.
e.g. the compiler can't optimise into a DLL, but Dynamo can
e.g. Dynamo can profile the code and optimise virtual function calls in ways that the compiler can't
-WolfWithoutAClause
"Gravity is only a theory, not a fact!""Our claim is that we can run 1:1 or [even] better than native speeds"
Bullshit.
Wake me when these guys go out of business. Been here, seen this. The x86 emulator guys made the same claims for their Mac-based emulators, almost word for word. (I won't even get into Transmeta's claims that have turned out to be similar bullshit).
This is just a special case of an optimizing compiler, which Java run-time optimizers also fall into.
These claims, as well as the claims for the "magic compiler" that can produce code better than humans, will never happen until we have real human-level AI that can "understand" the purpose of code. You can only get so far with narrow-vision algorithmic optimization, as proven by the failure of 40 years of research. (Failure, only as defined as producing code as good as a human can).
--
Sometimes it's best to just let stupid people be stupid.
this is not either an evolution or a revolution. it is a quick fix the legacy problems of "modern" computers.
but still...
a good idea. for example, the article states that a CISC to RISC translation would still be inefficient, how much so?? would a 1.4ghz athlon be equivilent to a 500mhz PPC or would it be better? could this all a much more usfull form of emulation, as in i cant afford a g5 MAC for macOSX so ill just use my athlon?.
also, with the claim of possible speed improvements accross RISC to RISC translation this may light a bit of a fire under the arses of some of the big players(intel-IBM) to build a new arcitecture with these optimizations in hardware.
this could be used as a tool for competition with transmeta with some good hardware backing it up. a CPU could be made as a base and the translation hardware could be pre-programmed to emulate multiple platforms. people would no longer have to worry about which arcitecture their WinCE apps are compiled for because their chip would run MIPS or ARM at nativelike speeds.
Just table based translation with few ifs engrained
in the code is not good justification for hype,
however some companies survive just that way.
Anyhow, they managed to emulate other chips in
hardware. Thats like carb in a car that can work
on the same fuels, alas the fittings are not same,
so they cannot be integrated into a engine
environment, with some heavy modificaions.
Being able to to run code from penitum on
your chips that just modifes registers and adress
ranges is interesting challenge, but its just
that.
Drivers written for 'common' enviroments
surrounding chips would not work on new platforms,
and if they will that will mean that new platform
is just an old one with new processor, that
to externals is just like plain pentium chip.
Feat like VMWare is more admirable, thanks to
those CISC commands that allow for multiputer
based technologies.
New statements like Apple made way ago, and so
as Sun did with their hardware are more forward
thinking than that mere table lookup embedded in
hardware.
Remember some companies survive on hype, hyping
old or new technology. Transmeta has firmly placed
itself in that market share, so it will be tough
for this company in near term.
is this.....is this for REAL?
great comedy company.
We aren't tied to the ancient x86 architecture because of legacy, we're tied to it because of manufacture contracts with x86's owner -- Intel. It's the industry, not software which is holding things up for cross-platform capabilities. Bring in a company with Intel's power and reach and we might get somewhere, but another emulator or translator isn't going to make a difference.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
I think that I shall never see
A program lovely as a directed acyclic graph
IBM was doing this exact same thing with DAISY, although the scope seems a bit narrower: http://www.research.ibm.com/daisy/ It's very interesting that we're just now talking about this stuff. It may get to a point where PC architectures will be able to do something similar to what an AS/400 does....the application is insulated from the hardware completely, and when transported to a new architecture, it automatically translates to run on the new architecture, fully able to exploit the abilities of that architecture.
I believe that some of you guys are missing the point. The quote was:
The author of the article makes it sound as though Transitive has invented DAGs. That's what is funny. Durinia is not a weenie making fun of their technology, and it's not necessarily an attempt on Transitive's part to dazzle.
"The only rights you have are the rights you are willing to fight for."
Ars Technica did an article on this topic a year ago. Check this link for the article.
We've had processor and machine emulators and processor independance for so long now...
SoftPC, Soft Windows, Virtual PC, XF86, Virtual Playstation, Java, WINE, Wabi, MAME, and so many others...
Why should this one be the news?
While Java was basically the only one that's tried to dislodge x86, they've all shown that while it's feasible to run another architecture's binaries ontop of a CPU, it's not the preferred way of doing things.
YAE (yet another emulator)
And big deal if it only translates a program from one binary arch. to another... Without an equivalent OS, the calls have nothing to be translated into...
And i could lead into the slashdot mantra of if all programs were opensource, we wouldn't need somethng as sloppy as an emulator anyhow...
Or am i missing something about the significance?
Exactly.
This is what that company that was mentioned a few months back was doing...
We all know that if you zip a file again, it gets smaller again, but it takes exponentially more time.
Couple that with the sort of exponential speed increase you get with repeated recompilation, and you get almost zero-sized files in a fixed ammount of time.
The exponential increase I speak of, is that if you get a 22% each time, you've got 48% increase after the second pass, and 81% after the third. It just keeps getting better.
The drawback with this is that because each recompilation of the program is a different binary (or it wouldn't be faster) it takes a new memory block. This means that the ram requirements approach infinity as well. Kinda nasty.
But, the patented part of this was that the company was going to use a Ram Doubler(tm?) type technology to compress the program in RAM, as well as the file. This then gets nearly infinite compression in a little over twice the time taken for single compression (there's some overhead) and about three to five times the RAM (there's more overhead in storage) required for just a standard 1-pass 30% compression algorithm.
The neat thing is it doesn't require quantum computing or anything, it's all off-the-shelf stuff, just linked in a neat way.
This'll revolutionize the market when they release it... we think MP3s are small! An 80GB HD will offer nearly endless storage.
Every PCI PowerMac has a 68K (CISC) to PPC (RISC) dynamic recompilation emulator in it that it uses for executing 68K code. And MHz for MHz, the execution speed of the 68K code when dynamically recompiled as PPC code, is roughly comparable (plus or minus 50%?) to the speed of the original 68K code on a 68K processor.
The very first PowerMacs (NuBus based) used instruction-by-instruction emulation to run all the old 68K Mac code, including some parts of the OS that were still 68K.
The second generation PowerMacs (PCI based) included a new 68K emulator that did "dynamic recompilation" of chunks of code from 68K to PowerPC, and then executed the PPC code; this resulted in significantly faster overall system performance.
Connectix later sold a dynamic recompilation emulator ("Speed Doubler") for Nubus PowerMacs, that did, in fact, double the speed of those machines for many operations, mainly because so much of the OS and ROM on the first-gen PowerMacs was still 68K code.
I think that dynamic recompilation has a bright future; x86 may eventually be just another "virtual machine" language that gets dynamically recompiled to something faster/more compatible/etc at the last moment.
-Mark
I don't see how the problem that I'd like to send you dynamic content via email without requiring you to be running the same CPU as I am is caused by closed standards. On the contrary, it seems to be an inevitable side effect of competition in the processor market. Yes, it is an obvious solution: given that I can do on-demand translation to the Java Virtual Machine, how much harder is it to do on-demand translation to the instruction set of a real CPU?
"Freedom means freedom for everybody" -- Dick Cheney
It's funny how things are heading these days. Java, .NET, and dynamically-translating processors are all "brilliant solutions" to a problem that was caused by closed standards in the first place.
Got Rhinos?
You're right in the case of the desktop and applications world. However, in the embedded world, such as cellphones and 802.11, this is VERY useful. The problem of multiple proprietary platforms is the current bane of the telecom industry, which this company is clearly targeting.
MetroWerks here in Austin did the emulation layer for Apple's M68K->power switchover. They did a really clever thing of identifying long "runs" of code that nobody ever jumped into the middle of, then they treated them as one big instruction with a lot of side effects, and optimized them as a block. (Not one instruction at a time, but the whole mess into the most optimal set of new platform instructions they could.)
It was quite clever. It's also quite patented, and has been since before the Power PC came out. (And in a sane world those patents would have expired by now, but with patent lengths going the way of copyright...)
Eventually, when the patents expire, this sort of dynamic translation will be one big science with Java JITs, code morphing, and emulation all subsets of the same technology. And somebody will do a GPL implementation with pluggable front and back ends, and there will be much rejoicing.
And transmeta will STILL be better than iTanium because sucking VLIW instructions in from main memory across the memory bus (your real bottleneck) is just stupid. CISC has smaller instructions (since you can increment a register in 8 bits rather than 64), and you expand them INSIDE the chip where you clock multiply the sucker by a factor of twelve already, and you give it a big cache, and you live happily ever after. Intel's de-optimizing for what the real bottleneck is, and THAT is why iTanic isn't going to ship in our lifetimes.
Rob
Here's the homepage for the company - Transitive Software
(Apologies for the Karma whoring)
There is no rennaissance in computing that will be ushered in by this product. We have already seen it's like with DEC's FX32 (intel to Alpha) and Apple's synthetic68k (M68k to PowerPC) as well as a number of predecessors (wasn't there something like this on one or another set of IBM mainframes) and current open source and commercial products (Plex86, VMware, Bochs, SoftPC, VirtualPC, VirtualPlaystation, etc.), all of which use some amount of dynamic binary translation, and none have set the world on fire. They are mildly usefull for some purposes, but the cost of actual hardware is low enough to kill their usefullness in most applications.
I wish these guys luck, but I doubt anyone will be too enthusiastic about this product. They might have stood a chance if they'd pitched this thing a year or two earlier (when there was lots of dumb money looking to be spent) but they are probably toast today.
This was being worked on a few years ago by some people at The University of Queensland. Unfortunately, they got tired of the project (and, if I remember correctly, that they weren't getting much popular support).
Their website is at :
http://www.csee.uq.edu.au/~csmweb/uqbt.html
"UQBT - A Resourceable and Retargetable Binary Translator"
To note, they mention that they got some funding from Sun for a few years. (Likely either causing or due to their work on writing a gcc compiler back-end that emits Java byte-codes.)
Let's say my source architecture uses interrupt-based I/O. My target uses memory-mapped. Will this translator be able to handle that?
To be honest, translating one CPU's version of 'CMP R1, R2' to another's doesn't sound like it will user in a renaissance of anything.
-Poot
How many people would want to run a "translated" web server? Database? Scientific appliction? How reliable can it be? Why not recompile it natively?
If we are talking about closed source:
The same questions except the last one plus lack of technical support for non-native architectures at least by some vendors (e.g. Apple).
I wonder if the specs for DAG will be open so that code can be compiled directly to it, optimized, and then distributed, saving the first two steps in the process. I can see commercial software vendors being all over this idea.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
This sounds an awful lot like the dynamic recompilation of MIPS to x86 done in many emulators (such as UltraHLE, Nemu, Daedalus and PJ64).
I've been working on the dynarec for Daedalus for about 2 years now, and currently a 500MHz PIII is just about fast enough to emulate a 90MHz R4300 (part of this speed is attributable to scanning the ROM for parts of the OS and emulating these functions at a higher-level). Of course, optimisations are always being made.
After reading the article, I'd be very interested to see if they can consistently achieve the 25% or so speedups that they claim (even between RISC architectures).
For those interested, the source for Daedalus is released under the GPL.
damn slashcode...
Wow! What innovative technology! I wonder when they will patent this so-called "directed acyclic graphs". And they picked such a cool name! It sounds so mathematical!
Okay, enough laughing at the expense of clueless reporters...
Doug Moen.
I have written a truly remarkable program which this sig is too small to contain.
While this is fascinating sounding technology, it sounds more like a solution in search of a problem. There are already software solutions for emulation (SoftPC, VMWare, etc). There are already cross platform language solutions (Java, etc) and so on. Despite this, the market for massively cross platform applications has not really developed. It isn't as if a 25% performance increase is whats holding back the 'rennaissance' the author speaks of.