On 11/11/15 7:58 AM, Alexander Kanavin wrote: > On 11/11/2015 03:34 PM, Mark Hatle wrote: > >> For the same architecture (i.e. MIPS64) and the same ABI (n64), the resulting >> data structures, packing and similar should all be standard. Only the >> generated >> instructions and execution order would/could change. >> >> So you would need a way to generate, cache, store the results by arch/abi >> combo >> in order to do this. The issue of course is that you would need to declare >> the >> arch and abi -- the tune files are the natural place to do this (we really >> are >> declaring it there ANYWAY), and the tune features in many cases may have >> already >> done this... >> >> Something to consider -- the alternative is the dual object (one generic >> [arch/abi], one optimized for the tune) that can be used to run on QEMU. >> Twice >> the compile time but should work fine. > > Hmm, maybe it's simpler to just fix QEMU so it can handle the missing > instructions?
Unfortunately it's not reasonable in my experience. The problem is that anyone who implements a BSP/machine that includes so far unknown instructions to qemu would be required to implement them. As most people don't understand the instruction implementation in QEMU, I'm not sure this is reasonable. I really want to get the gir support into oe-core, but I'm concerned that doing things this way is going to cause a significant gap in functionality for many of the machines that use OE. --Mark > > Alex > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
