Let's ignore that you'll have to licence from Intel to do this...

Let's ignore that you'll have to licence from Intel to do this. How difficult would it be to build a "translation layer" for cpus of our choice to handle the x86(-64) instuction set to an extent that running windows or even current AAA games would be possible?

Other urls found in this thread:

en.wikipedia.org/wiki/PowerVM_Lx86
en.wikipedia.org/wiki/Compatibility_card
youtu.be/A_GlGglbu1U?t=80
en.wikipedia.org/wiki/Transmeta
twitter.com/SFWRedditGifs

it already exists. kys.

There is no need to license x86 anymore, it is not covered by patents since it's over 20 years old.
What you want is an emulator, and it already exists (see QEMU as an example), but performance is not up to par and you might have problems with some x86 extensions (like AVX and SSE), which are still covered by patents.

>JNBE
>jump if below or equal
uh

>There is no need to license x86 anymore, it is not covered by patents since it's over 20 years old.
>except for the extensions used by pretty much all modern software
Also
>what is x64

Didn't you read when I said
> you might have problems with some x86 extensions (like AVX and SSE), which are still covered by patents

>what is x64
Yet another extension still covered by an AMD patent

I did indeed read that. It doesn't change the fact that your post is retarded.
>Yet another extension still covered by an AMD patent
And you didn't mention this... why, exactly?

I can tell you're not sincere and are just looking to argue with that user. That's really rude and you should feel bad.

He started his post off with
>There is no need to license x86 anymore, it is not covered by patents since it's over 20 years old.
Which is entirely meaningless to anyone developing software today.

I imagine a hardware level "emulator" (actually more a translator) to be faster and less cumbersome compared to a software emulator. so I'm prett sure it's not an emulator that I want thus I made this thread.

I mean if people could write an something like a playstation emulator it should be possible to design hardware to work like x86 even though it isn't (and it doesn't suck).

You're just trying to start an argument with me now instead. Shame on you.

I beleive some IBM POWER systems have hardware assistance for their Lx86 handling methods.
en.wikipedia.org/wiki/PowerVM_Lx86

Apple did this years ago as well for their systems and I believe at NeXT as well.
en.wikipedia.org/wiki/Compatibility_card

I'm almost positive SUN and Oracle have done this for DEC shit before but not commonly.

>your post is retarded.
How so? OP wanted to know if an emulator is feasible, and it is, hence my QEMU example.
As if it is good enough to run muh gayems, I said why it probably wouldn't due to such extensions and the emulating process itself.

>And you didn't mention this... why, exactly?
Do you want me to list every patent-covered extension? And most software don't even require it (specially games)

It's okay, it's not like I have anything better to do other than browsing this cantonese cartoon forum

Well, OP did start with
>Let's ignore that you'll have to licence from Intel to do this.
So I though it would be a nice a addendum


Well, you sure can implement it in hardware, and it would be many times faster than a software solution without a doubt, but the design would be overly complicated and expensive. In the end it all boils down to: is it actually worth doing?

I believe that's something software-based, much like Apple's Rosseta. Feel free to correct me if I'm wrong.

>I believe that's something software-based, much like Apple's Rosseta. Feel free to correct me if I'm wrong.
I think it was hardware accelerated sometimes but not always. I'm not actually sure because of the nature of it (Enterprise tier). I'm sure if you were a big company and asked IBM they would do it for you.

The public documentation for the system as a whole is somewhat sparse now, but I remember looking into it a while ago and being confused ifi t was software or hardware emulation because of conflicting statements on official documentation but for different hardware platforms.

Maybe it was purely software after all.

After googling a bit about it, I can see how confusing the documentation is lol

I'm leaning to believe that there was in fact some hardware acceleration involved, but again, it's hard to confirm this through their docs.

>is it actually worth doing?
I would like to say that it is.

>en.wikipedia.org/wiki/Compatibility_card
I wonder if apple will do something like this again if they move to ARM. Then again Windows does this in software for their ARM stuff.
youtu.be/A_GlGglbu1U?t=80

I can't remember which compiler talk it was but I remember Rob Pike talking about how all intermediate ASM languages when talking about the Plan9 and Golang compilers, given the similarities between architectures combined with the power today, it really does seem like you can get away with software only emulation layers using some form of recompiling. It's what all those console emulators do anyway.

What if you made a dual socket motherboard but instead of it having 2 of the same socket it had 1 for x86 and one for your target processor?

if you had the money and technology available to build a hardware emulator, which is simply another cpu, then why not build a cpu for the instruction set you want than having a cpu for the cpu.

It's called QEMU. Now go kill yourself.

>I imagine a hardware level "emulator" (actually more a translator) to be faster and less cumbersome compared to a software emulator.
And you'd be wrong. A software layer has the advantage that it can JIT-compile the translated code and apply optimizations to it.

It's vastly different then a cpu since it's just a translator. It doesn't neccesarry have to compute anything. I think it might be possible doing it with a FPGA chip. Thus, I imagine this approach, using existing CPUs is very much cheaper and doable compared to designing a whole new CPU. Of course if I had the money and the ressources I'd really prefer making my own CPU.

if it doesn't need JIT-compilation because it can understand the data natively, that's a whole lot of number crunching that isn't needed in the first place.

Transmeta already did this.

en.wikipedia.org/wiki/Transmeta

>if it doesn't need JIT-compilation because it can understand the data natively
By that point, what you've built isn't a "translation layer for cpus of our choice", but an x86 processor, quite simply.

Is there perhaps any part of a typical recompiler cycle that would benefit from being hardware assisted? For example having something that implements a subset of instructions that assist with optimization somehow, not that exactly, that's just the example, but something along those lines.

I guess what I'm asking is, in a typical recompiler system, where is the tension mostly and can it be alleviated with hardware?