locked
Is that possible? RRS feed

  • Question

  • Respectful Microsoft,

    I have an idea, that might be ridiculous! But I have found ways to seek help here! If some a company developed a processor using ISA something different from x86, but this processor has enough power to simulate the entire x86 architecture! Take ISA XYZ for example, then if someone developed an instruction set translator, translating between x86 and ISA XYZ, and provided enough emulation for the x86 platform. Then this system would be able to support Microsoft Windows, take Windows XP, for example. Because all the codes, Windows XP and applications running on it, have to be translated one by one onto the ISA XYZ, before running. Will it be possible that a special application written in ISA XYZ, to work on this supported Windows XP, utilising of resources provided by Windows, if enough support was already provided by that translator?

    Respectful Microsoft, is this very situation possible?

    Supplementary Explanation: The underlying ISA translator have capabilities to aware the native ISA XYZ codes, and not let them to be translated, but execute directly with enough assistants. Or in other words, Windows is working under ISA simulation, like it in  yesterday's Transmeta computer; while special Applications work on the native mode. Those special applications represent themselves with native ISA XYZ codes, so they are not portable to other real x86 processors based computers. The initial purpose to design such a system is that one do not want others to clone their computers, and do not want to develop another OS rather than Microsoft Windows. So is this up-side-down idea possible?

    I have to say that I have completely no capabilities to design such a computer, but I just have this very idea for years. I told them to lots of people, but most times, I was laughed at as a crazy.

    I've gotten in touch with Windows XP Professional x64 since early 2005. My very first AMD64 based computer was not good enough with it, I made lots of complaints about it, and even throw that computer away when I was crazy. But today I understand why Microsoft developped such a 64-bit OS, rather than a 32-bit underlying resources to support 64-bit applications. Maybe the most important reason is that Microsoft wanted the 32-bit applications could also take advantage of the underlying 64-bit computing resources, such as 64-bit virtual memory (4GB rather than 2 or 3GB), 64-bit GUI and so forth, in other to enhance the performance of 32-bit applications on 64-bit Windows too, even though it consumed a bit more hardware resources.

    Sunday, November 29, 2015 12:22 PM

All replies

  • What's the main advantage here? RISC architectures have been making a similar argument vs CISC and technology keeps moving CISC forward and leaving the majority of RISC to low power solutions. There would have to be a compelling reason to move away.

    http://pauliom.wordpress.com

    Tuesday, December 1, 2015 8:45 AM
  • Thank you for your reply, but the point that I discussed here is not related with CISC and RISC. But use another architecture (rather than x86) to support Windows (IA-32 or x64) with help of ISA translator, extending the Windows itself to support applications written in this architecture (ISA XYZ). Or in other words, Windows is executed under container, but applications are running outside that container. The main advantage for this idea is that system focusing on Application, video post processing for example, which would consume lots of CPU time would benefit from it without needing portable Windows to this ISA XYZ architecture, and without needing migrating the processors from ISA XYZ to x86.

    P.S. Someone on some a Chinese forums blocked me for this very absurb idea! Someone on some another site called my ideas waste their time and energies. So if you think my idea is far more from practical or absurb, please do not waste your treasurable time and energies to make any reply! In my own opinion, this thing has its own value for some in-house computer. The very best thing for it is that OS (Windows) could be cloned, but for the performance of applications could not be cloned. That would make the same things different.

    Wednesday, December 2, 2015 12:45 AM
  • About more than 12 years ago, the very first time I got in touch with .net framework and Common Language Runtime. I knew Microsoft must want to provide some an architecture neuter container to help applications programmed once, but supported on many different platforms, then there were IA-32, Itanium and 64-bit Alpha. I saw nothing special within .net framework 1.0. Even though .net framework 1.1 was coming with Windows Server 2003 and Windows XP 64-bit Edition Version 2003, but there was no native Itanium support. Only when .net framework 2.0 released about 10 years ago, things happened to become different. The applications running on .net framework are the examples of codes from ISA rather than x86, for its nature of codes interpretation, the performance could never get close to the applications written in native codes.

    For 64-bit Windows, it provides a backward compatible container, used to host applications written in IA-32. The Itanium edition adopted two methods, running within x86 hardware based engine or running within a ISA translator. Because x86 hardware based engine is just additional part of original Itanium processors, so the performance is comparable not good enough, and was replaced by the latter one. The x86 processor provides a hardware level support for the IA-32 programmes, then this container is implemented on the x64 ISA level rather than providing additional hardware or software translation.

    Operating System, from most books of computer science, it is another machine represents itself on bare computer hardware, provides resources and mechanism towards the software surviving above on it. If this machines could be virtualised a further step, to be represent itself in ISA-neutral codes, then it would be much easier to port onto the new architecture. How to make it work on the ISA-neutral codes? Or what is ISA-neutral codes? Byte codes or codes in JVM? Or something else? There is completely no ISA-neutral codes, but we could treat codes from some an ISA as neutral. Then use some another architecture to support it. There possible be to two ways,

    First, ISA translator, like what it does with Transmeta processor or ISA translator for Itanium processors. But this time not only translate IA-32 codes into its native codes, but also enable its native codes run under Windows without problems. IA-32 architectural registers might be used as indexes when system interruptions interrupt the current program written in native codes. The Windows save those indexes into its PCB, but the ISA translator could reuse those indexes to restore the environment for the interrupted native applications.

    Second, modern processors tend to be designed more and more complex, take x64 and Cell for example. x64 processor is the product of hybrid of both IA-32 and AMD64; while Cell processor is the product of hybrid of PowerPC in two forms. If future Microsoft develop their own neutral ISA, which is designed for their future Windows products. Then the processor manufactures must implement a necessary operating mode, OS mode, providing environment for Windows to work; and its native mode, application mode, which is provided for all applications at native performance. This OS operating mode might be emulated within microarchitecture, or the micro-architecture is strong enough to work for instructions from two ISAs. This idea hears a bit absurd, and stupid. But if yesterday's Itanium processor provides those two operation modes rather than x86 engine, which might be further accelerate the migrating from x86 towards IA-64. In other words, processor manufactures could develop their own architecture independently, only need to do is to provide OS operating mode,  besides that nothing or few need to be considered. And Microsoft could also have chance to implement some components not all in native operating mode to native-lised  the whole system.

    The eventually goal might be that, all the future processors could run Windows directly, but not the applications. This idea might help a computer to be more usable, even though innocent!

      

    Wednesday, December 2, 2015 7:46 AM
  • As I said, it is similar to the CISC vs RISC argument in the sense that what is the benefit to *Windows* in supporting this? Sure in theory it would allow Windows to run on more systems but is that really a major benefit? You already have app containers in cloud computing so yes on theory in it's a nice idea, but I don't see the benefit for Windows to invest in this.

    http://pauliom.wordpress.com

    Wednesday, December 2, 2015 7:59 AM
  • As I said, it is similar to the CISC vs RISC argument in the sense that what is the benefit to *Windows* in supporting this? Sure in theory it would allow Windows to run on more systems but is that really a major benefit? You already have app containers in cloud computing so yes on theory in it's a nice idea, but I don't see the benefit for Windows to invest in this.

    http://pauliom.wordpress.com

    Thank you very much, but there is no biz with CISC vs RISC argument at all. That might be a future view of porting Windows on different platforms.
    Wednesday, December 2, 2015 9:36 AM
  • Let me put it another away. People spend X on developing Windows for x86/64. Why spend Y on anything else when x86/64 keeps improving enough to not make it viable to look at anything else?

    http://pauliom.wordpress.com

    Thursday, December 3, 2015 10:07 AM
  • Sorry, I don't know what you mean here, but I am sure, at around 80%, that you did not even read what I wrote here at all! If one do not under-stand other's view, how can he/she see something clear? If you spend money N on Surface RT, but it will never mean you would not put 2xN for a iPad Mini 4. Another question what is the differences between Surface RT and iPad Mini 4, if someone just needs a electric map? At that point, there is nothing different! But they both are very different! I wish this is my final answer towards your question!
    Thursday, December 3, 2015 12:52 PM