As long as the assembly is "well behaved," it should be possible... It won't work with self modifying code, but that's not used too much anymore anyway. But, as you point out, the most interesting (at least, to me) targets for translation are only available as binaries.
As for fat binaries, they're OK when you only need to support two architectures, but can you imagine the size of a netscape binary with support for nine architectures? Also, most linux software is available as source which can be recompiled.
If you're referring to a translator that takes an x86 file as input and spits out a ppc file, that would be rather tough, as it is difficult to know a priori which is code and which is not.
However, dynamic translation of segments of code as it runs is certainly possible. FX!32 for NT/alpha does this with x86 binaries. I've been working on something to do this for linux (currently x86->alpha, but other sources and targets can be added)... As soon as I can get the code cleaned up I'll put it a public CVS server.
I don't buy that as a valid argument. Far and away the vast majority of people who use "open source" software will never alter a single line of code in it.
I think you're missing the point. Just because the individual users may not be able to modify the software themselves does not mean that nobody can provide the needed fixes and/or features. With proprietary software, that is exactly the case if the authors decide not to either do it themselves or provide someone else with the source.
And if VMWare went out of business I doubt much could (or would) be done to advance the software after the companies demise.
Nothing could be done since the source would be locked away. Or are you claiming that there's nothing that anyone would desire to add to VMware? If so, read some of the other comments wrt IDE/SCSI. VMware is by no means in a state of perfection.
Paying for software makes sense just like paying for other products in this world. And while it is nice to have the free software that does exist there is nothing wrong with people like VMWare and their commercial products.
The primary issue is not the money, but the freedom. What if I want to use raw SCSI disks? What if I want to port it to alpha? What if I want to add some nice debugging facilities? If the proprietary software does all you want it to do and you trust them to provide continued support, then fine, there's nothing wrong with that. But there's also nothing wrong with writing a free alternative if you're not satisfied with the proprietary offering.
Of course, on the dvorak keyboard those much praised 'hjkl' keys are where 'jcvp' are on a qwerty... not very pleasant. Plus, those keys require multiple contexts, which I find far more obtrusive than moving my hand over a little to access the arrow keys. Just because the human brain *can* deal with multiple contexts doesn't mean that it is more efficient doing so.
That's not run through a preprocessor? Why would anyone manually write something such as (1?4:4) instead of 1? What about the spurious semicolons all over the place, indicating that a macro was expanded to nothing? How about all structures being defined in the source files, rather than in header files? As for obfuscation, I would say that function names like nvFunc363 qualify. If that's the way the code has always looked, I pity those who had to work with it.
They're missing the low-level details on how to talk to the card; instead you have to go through the obfuscated source code they provide. It's not completely useless, but it's not completely useful either.
Except that GIFs are limited to 8-bit color, which wouldn't exactly bring out the best in the screenshots. Using GIFs would also increase the file size quite a bit.
And where exactly are the hard lines in a q3 screenshot?
I would venture that it is quite funny. I apologize if I sound rude, but is it really that difficult to ignore something in which you can't appreciate the humor rather than whine to the person that said or wrote it?
The SB Live driver will be GPLed, according to this page. The ATI glx driver is not being developed by ATI (they released specs instead of a driver) and will have an X-style license. As for Aureal, we'll have to wait for the official announcement.
This really isn't a departure from what they've done in the past; Solaris runs on IA32 hardware as well. Perhaps the intent is to make it easier for people to try out Solaris on their current hardware, hoping that next time they buy hardware it will be from Sun. As for W2K performing best on Sun hardware, I would be quite surprised if it runs on Sun hardware at all. NT has never run on Sparc before, and last I checked Sun and Microsoft weren't exactly sleeping together.
Please elaborate on how, precisely, Debian evolves at a "snail-like pace". Debian is rather conservative with what it labels as "stable", but the unstable branch (which, despite the name, is quite stable) is almost always up to date. It has been using glibc2.1 for quite a while now. Slackware, OTOH, hasn't even managed to support non-intel platforms yet.
What would be the point of that, though? No existing x86 software would be able to use the 64-bit x86 extensions, and no Intel chip supports them, so there is no compatibility gain with using a 64-bit x86 ISA. What would *really* be nice would be a chip that uses the Alpha architecture with some extensions to help out translation of x86 code, such as condition codes and sub-longword operations.
for companies like Progressive Networks to compile their software for the alpha? Provided that their code doesn't have 64-bit issues (and there's an Irix 6.x version, so it probably doesn't) all that's necessary is building a cross-compiler or ftping the code to an alpha box and typing 'make'. I'm guessing there are at least as many linux/alpha users than solaris/x86 users (which they do support)... and probably a larger percentage of the linux/alpha users would use something like realplayer.
Presumably, if the optimized batch of native instructions failed, it would only retry once, with no optimization so it could accurately determine the non-native instruction that caused the fault. At that point, it could raise an exception.
As for running the instructions "for real", it seems as if it does run them "for real" the first time, but holds the results in a temporary buffer which is only committed when the sequence completes successfully. Otherwise, the common case (no fault) would be slow, since there would be reexecution of the same code.
OK, great idea! Now, tell me where I can get a copy of Win98 for my alpha... oh, and you wouldn't mind sending me a free hard drive to install it on, would you? And maybe a check to cover the time I spent installing and rebooting, and backing up data if your hard drive never shows up, while I could be doing something productive?
Thanks, AC, I don't know what I'd do without your guidance. Your idea is much better than simply taking my money to an ISP with a clue. Really.
You make a good point, but remember that even with the old style of anonymous posting, it would still be possible, with enough effort and maybe a subpoena or two, to find out who the poster is. Even if slashdot doesn't log a username for the post, it could still log the IP. If it's a static IP, then the poster has been found. If it's a dynamic IP, then the ISP should have in their logs who was using the IP at the time. The only truly anonymous method of posting is to use an anonymous reposter which logs nothing about the poster.
This is, of course, assuming that slashdot logs IPs for anonymous posts, but from previous talk about temporarily banning posting from abusive IPs, it seems that it does.
Slashdot Mirror
As for fat binaries, they're OK when you only need to support two architectures, but can you imagine the size of a netscape binary with support for nine architectures? Also, most linux software is available as source which can be recompiled.
However, dynamic translation of segments of code as it runs is certainly possible. FX!32 for NT/alpha does this with x86 binaries. I've been working on something to do this for linux (currently x86->alpha, but other sources and targets can be added)... As soon as I can get the code cleaned up I'll put it a public CVS server.
you can view it with an external viewer, and you don't have to deal with pop-ups and banners. ;-)
I think you're missing the point. Just because the individual users may not be able to modify the software themselves does not mean that nobody can provide the needed fixes and/or features. With proprietary software, that is exactly the case if the authors decide not to either do it themselves or provide someone else with the source.
And if VMWare went out of business I doubt much could (or would) be done to advance the software after the companies demise.
Nothing could be done since the source would be locked away. Or are you claiming that there's nothing that anyone would desire to add to VMware? If so, read some of the other comments wrt IDE/SCSI. VMware is by no means in a state of perfection.
Paying for software makes sense just like paying for other products in this world. And while it is nice to have the free software that does exist there is nothing wrong with people like VMWare and their commercial products.
The primary issue is not the money, but the freedom. What if I want to use raw SCSI disks? What if I want to port it to alpha? What if I want to add some nice debugging facilities? If the proprietary software does all you want it to do and you trust them to provide continued support, then fine, there's nothing wrong with that. But there's also nothing wrong with writing a free alternative if you're not satisfied with the proprietary offering.
Of course, on the dvorak keyboard those much praised 'hjkl' keys are where 'jcvp' are on a qwerty... not very pleasant. Plus, those keys require multiple contexts, which I find far more obtrusive than moving my hand over a little to access the arrow keys. Just because the human brain *can* deal with multiple contexts doesn't mean that it is more efficient doing so.
Why not make it user configurable?
If the user wants to read posts marked as "offtopic humor"
he or she can set it to +1, and if not, to a -1.
64-bit PCI has been around for a while; I've got two 64-bit PCI slots on my alpha. There aren't many 64-bit cards, however.
That said, I would love to see q3 on linux/alpha... but I doubt it'll happen.
That's not run through a preprocessor? Why would anyone manually write something such as (1?4:4) instead of 1? What about the spurious semicolons all over the place, indicating that a macro was expanded to nothing? How about all structures being defined in the source files, rather than in header files? As for obfuscation, I would say that function names like nvFunc363 qualify. If that's the way the code has always looked, I pity those who had to work with it.
They're missing the low-level details on how to talk to the card; instead you have to go through the obfuscated source code they provide. It's not completely useless, but it's not completely useful either.
And where exactly are the hard lines in a q3 screenshot?
Presumably because it wasn't registered until last Friday.
I would venture that it is quite funny. I apologize if I sound rude, but is it really that difficult to ignore something in which you can't appreciate the humor rather than whine to the person that said or wrote it?
The SB Live driver will be GPLed, according to this page. The ATI glx driver is not being developed by ATI (they released specs instead of a driver) and will have an X-style license. As for Aureal, we'll have to wait for the official announcement.
This really isn't a departure from what they've done in the past; Solaris runs on IA32 hardware as well. Perhaps the intent is to make it easier for people to try out Solaris on their current hardware, hoping that next time they buy hardware it will be from Sun.
As for W2K performing best on Sun hardware, I would be quite surprised if it runs on Sun hardware at all. NT has never run on Sparc before, and last I checked Sun and Microsoft weren't exactly sleeping together.
Please elaborate on how, precisely, Debian evolves at a "snail-like pace". Debian is rather conservative with what it labels as "stable", but the unstable branch (which, despite the name, is quite stable) is almost always up to date. It has been using glibc2.1 for quite a while now. Slackware, OTOH, hasn't even managed to support non-intel platforms yet.
Lynx users could download and view the image, or set up lynx to launch an external viewer. As for modem users, just keep the image small.
Assuming you mean mobo+chip... My 164SX board with a 533 MHz 21164PC draws 90 watts. Of course, you probably meant PC motherboards. :-)
What would be the point of that, though? No existing x86 software would be able to use the 64-bit x86 extensions, and no Intel chip supports them, so there is no compatibility gain with using a 64-bit x86 ISA. What would *really* be nice would be a chip that uses the Alpha architecture with some extensions to help out translation of x86 code, such as condition codes and sub-longword operations.
for companies like Progressive Networks to compile their software for the alpha? Provided that their code doesn't have 64-bit issues (and there's an Irix 6.x version, so it probably doesn't) all that's necessary is building a cross-compiler or ftping the code to an alpha box and typing 'make'. I'm guessing there are at least as many linux/alpha users than solaris/x86 users (which they do support)... and probably a larger percentage of the linux/alpha users would use something like realplayer.
As for running the instructions "for real", it seems as if it does run them "for real" the first time, but holds the results in a temporary buffer which is only committed when the sequence completes successfully. Otherwise, the common case (no fault) would be slow, since there would be reexecution of the same code.
Thanks, AC, I don't know what I'd do without your guidance. Your idea is much better than simply taking my money to an ISP with a clue. Really.
This is, of course, assuming that slashdot logs IPs for anonymous posts, but from previous talk about temporarily banning posting from abusive IPs, it seems that it does.
ITYM a 533MHz 21164... if you can get a 21264 of *any* speed for $1500, please tell us where. :-)
You must be proud!
Come back when you can keep that Mac up, under normal usage, for months at a time and you may have an argument.