Is there anything stopping an AMD CPU from communicating with

>>58996461
drivers

It would open a portal which would most likely require a fourth-party chipset.

>>58996461
only one way to find out

>>58996461
This is extremely retarded.
86-64

>>58996461
some interconnecting hardware would be needed, and it would likely cause enough latency to not make it worth using

>>58996461

Theoretically, yes. But in any sort of conventional use, it really wouldn't be usable. The complexity of the third party chipset, firmware, and software would be cripplingly massive. To the point where, likely, the power you'd attain doing this would be moot given the overhead of managing the two.

It'd be "more possible" in a non-conventional unix environment, where each processor and it's related supporting electronics could be treated as it's own, discrete, processing element instead of trying to make the two work together, but at that point, getting Co-Processors like the Intel Xeon Phi would likely be the better bet.

It would be interesting to see someone make a socketed Xeon Phi style card for servers or workstations, however, that would allow AMD/Intel to offer you a way to offload/split heavy-duty workloads maybe not suited for massively multi-parallel off to a separate processor. I suppose the biggest difficulty there would be cooling and power, really.

>>58996461
in the 90s AMD cpus often worked with intel based socketed motherboards. I remember the user manuals used to include the different brands of cpus the board was compatible with.

>>58997833
thats what amds business whas for a long time, selling chips for 486 and pentium boards that were cheaper and relatively faster, tho the FPU usually sucked.

thats where we got the start to our lovely PR ratings

ITT: How can we stop the inevitable death of AMD processors?