Yeah, but that is assuming that Nintendo already discusses things in a open channel. And it's been well proven that what ever cards they have, they play it close to the chest... Look at OpenGL/Vulkan, Nintendo has been a member on OpenGL for years. It is very rarely that you hear input from the company on that spec. They use it, but that seems to be about it. There is no real company effort to have some say in the direction of the spec, and I highly suspect that there resent membership with Vulkan will be much of the same.
Yes. I was giving a negative example - I know nintendo would hardly do that. They're not that kind of company.
That said, if I am to make an guess... The merged there handled and console R&D's for a reason. And there are already hints that, going forward... the 3DS will likely be the last of it's kind. What ever they are branching from would likely be internal.
Precisely. The writing is on the wall. If they can unify their game as well as system divisions, they'd be at a net gain. The only reason nintendo would go x86 on the home end, Zen non-withstanding, is IFF the cost of Puma hw was so cheap that it outweighed the cost of supporting two different architectures at the OS level. The thing is, I cannot imagine AMD offering nintendo so much better prices on Puma APUs vs A57/A72 APUs.
You know, that might also be something to consider... Just about everyone knows that Nintendo is VERY picky about prices and pricing.
Every platform holder is ; ) Nintendo are just selling to a bit different demographics than sony/ms.
You don't need to take leadership. You fork your version, patch it and submit pull requests upstream. This is a super common process in the open-source community.
You entirely glossed over my post - the one part where I asked you why you think Sony/AMD took ownership over LLVM tree domains. Let me elaborate for you:
1. You branch OSS Foo.
2. You make it work in
your system - at the very top that includes patching interfaces for compatibility/efficiency/glaring stupidities, but also throwing out / bringing in of arbitrary portions of functionality.
3. You start actively using it. You encounter myriads of: (1) bugs, (2) more incompatibilities with your pipeline* and (3) actual opportunities for optimisations and genuine new Foo features. You submit patches / send pull requests for your first, perhaps second and surely third category**. Those go into some maintainer's incoming box and/or you wait for the next RC merge window. Why wait for a release? Because you surely don't want to use head of Foo tree for actual production of your software. Either way your patches find their way upstream with a considerable delay.
In the meantime (particularly on really active OSS and similarly active closed projects) things have piled up and you're essentially maintaining your internal branch, arbitrarily-deviating from Foo's fork point. And since you don't work full-time on maintaining Foo, but you actually have other duties on your bills-paying project, your own timeliness on those patch submissions / pull requests is not impeccable either - you miss a window or two, etc.
* things that originally looked ok-ish, but in practice turned out dead ends.
** making the world a better place (tm) in the process, etc. Of course those are not just some surgical touches - they are normally accompanied by their unit tests, or at least fixes in preexisting ones.
So at the end of the day, my dear Somnid, it might be more efficient if you just took ownership over some domain of Foo and effectively made other contributors honour your day-to-day work and world views as much as you honoured theirs. Of course all that could happen only once you've wrestled successfully in Foo's internal political struggles. And this is why Sony took ownership over some portions of the LLVM tree - Sony needed a good compiler toolchaing for the ps4. And apple generally stepped down as the main owner, so the political landscape was generally open for shuffles.
They've invested billions into their own chips which are among the best out there and iOS as a product is not suited to larger devices where x86 reigns.
iPad Pro is a large enough device so that apple could've used a core-m for it - same as in their macbooks. They did not.
That x86 build for the emulator is likely not a lot of maintenance ..
That's an interesting assumption. It's as much maintenance as twice the integration and verification work.
.. but provides huge benefit developers who aren't working on ARM devices (Perhaps there is something worth learning here, hmmm).
Sure. Until recently the emu was the only way devs could run any iOS code without forking for the annual AppStore fee. This changed with iOS 9, though.
Hell Android keeps MIPS support around probably because that too isn't super expensive to maintain, I can't even name a single MIPS Android device.
This is not some 'goodle did on a whim' act. Android is accessible to 3rd parties and there's sufficient interest in MIPS across the globe for the architecture to see continued support. Imagination and a good portion of the Chinese market (where Loongson is their national CPU) make sure of that. The parallels to closed ecosystem entities like nintendo or apple are just not as strong as you think.
