Arm doesn't have the patents for x86 or x64 architecture, . Only producers of x64 is AMD and Intel. x64 actually was first done-up by AMD. Arm is a RISC processor (reduced instruction set computing), vs x64 and x86 is a CISC (Complex instruction set computing). You can read more about ARM chips at Wikipedia.org link here: https://en.wikipedia.org/wiki/ARM_architecture (maybe right-click, open in new window) RISC processors are great with simple commands, but complex multimedia really throws them for a loop - unless dedicated multimedia processors are present. Basically, it's a much simpler processor. It makes a super-duper calculator/compiler - but it stinks at breaking down complex multimedia. It takes less 'hops' inside the processor for a single basic processing operation to take place in RISC vs CISC (x64 / x86), but the scope of the RISC is much more limited. Motorola used to make RISC processors to go into MACintrash computers back in the late 80s / early to mid 90s until they switched over around the core2 era around 2007. RISC cpu's are also what's used in most video game systems until they used x64 AMD octa-core chips (2ghz 8-core bulldozer) starting around 2012 or so for PlayStation and XBOX. Applications have to be compiled for the type of processor they are meant to run on. Trying to run an application with one type of compiled code on the wrong processor will produce an error something along the lines of "this will not run on your version of Windows". On linux, you can download an application's source (if it's open-source) and use the (should be!) built in compiler like gcc (whatever version you have with your distro) to configure, make, and then install the application, for your OS distro and processor config. Long story short, you won't have Beamng.drive on your cell phone anytime soon. Not within the next few years anyways. Mobile tech has to catch up, because it's lower-power envelope, it's usually much less fast ghz-wise than high-end desktop chips that really make cake of this game/simulator.
This doesnt address big.LITTLE and why similar tech hasnt been employed in x86/x64, also numerous mistakes. There is a 3rd producer opf x86 and x64 chips, this is VIA. Media throws CISC and RISC for a loop, both have pros and cons for most tasks. mac stopped using motorola long before jumping to intel. It actually jumped to IBM powerPC, a RISC architecture with a far far higher realworld throughput than intels 8086/derivitives (same for the motorola actually, the RISC chips of that era shat all over CISC), particularly in multimedia (what was that about media throwing RISC for a loop? All the dedicated media workstations of the time were RISC....). Its just PowerPC didnt get money invested into its further development, its performance stagnated, not for any architectural reason, just lack of any development effort. x86 caught up and overtook, apple switched. Simple. Trying to run code for wrong processor type wont produce that error. Windows before opening the executable does a quick check and produces that error. Actually attempting to run the code, the behaviour is entirely non definable. Machine code is just a sequence of bytes. How each processor architecture responds to it is different. But either processor will see a sequence of bytes and try to do something with it. Its not gonna miraculously see oh this is wrong, its gonna try and decode it and not actually freak out until there is a genuine exception state hit. Weird things will likely happen (though I have witnessed a byte stream that does produce a valid output for both PIC and AVR processors before, incredible shit). Being able to download an applications source and recompile is nothing to do with the operating system or processor architecture. I have C compilers setup on windows, I can download and compile chromium as its open source. On linux I cant just download and compile steam because the source isnt available. Thats just open source software versus closed source software and does not factor into this at all. And ultimately none of this changes that big.LITTLE hasnt been addressed. And ARM technology in which you have 2 sets of cores. High performance ones and low power ones. Typically something like 4 ARM Cortex A53's and 4 Cortex A73's. In big.LITTLE. Default processor state is to disable big (the 4 A73s) and run as a quad core LITTLE machine. Then when higher performance is required switch the LITTLE off, load the register states and cache over into big, run big. Extreme circumstances it can bring both sets online and run as an octacore. Why is this not done in x86? You have more flexible control over each core already. Where most ARM SoCs require all 4 cores to run at the same clock speed, intel and AMD allow each core to run different clocks anyway and conserve power when necessary. Intels core m3/m5/m7's can turn hyperthreading on and off on the fly and shut down cores. I believe the scaling order is as follows: 1 core HT off, 1 core HT on, 2 core HT off, 1 core HT on and 1 core HT off, 2 core HT on. Clock speeds can drop as low as 200MHz and as high as 3ghz in some models. Each physical core can do that independently. So why no big.LITTLE? Its already so flexible that its not required.
oh ok, so its not necessary since the cpus can just turn cores on and off and clock high and low. My MediaTek tablet MT8163v/b (1.3ghz A53) can shut off cores and adjust core speed depending on load, CPUZ shows this. CPUZ also shows that my phone keeps all 8 A53s at 2.0ghz when touching the screen which is Googles annoying touchboost, it also doesnt seem to park cores, but i guess it does have good battery so it does but isnt reported
Your mediatek can only turn off either set if 4 and adjust clock for either set of 4. Can't control whether each core is on or off individually or the clock speed for each core individually
oh ok, im probably going to take it back or get an Asus Transformer since Android isnt suited to 10inch screens and windows 10 is quite nice. Also an Atom blows this mediatek out of the water imo
