Peter Maydell writes: >> The only realistic way to get started with such setups I see is to create a >> new target-xxx for the specific mix, define TARGET_LONG_BITS etc. >> appropriately in a new cpu.h, compile the needed target-xyz/*.c to unique >> xxx-softmmu/xyz-*.o and dispatch from a cpu_init() to the two cpu_*_init().
> Yuck. Longer term if we want to support this kind of heterogeneity > we should be removing all the compile-time assumptions and generally > making the target-specifics suitably contained rather than leaking > into the rest of the code. Yup, this sounds like pointer tables. That's one of the main reasons I advocated C++. Another reason is improving code maintainability through templates (without impacting performance). >> I'm guessing we may need to distinguish the TBs at runtime? Reserving >> log2(#architectures) bits in the TBFLAGS might do, but feels ugly. >> Probably a lot of other issues I'm not seeing yet. > We may want the tb cache to be per-core anyway (and one thread per core), > which would avoid the problem of trying to wedge everything into one set > of tb_flags. Well, AFAIU if targets have different ISAs, the same physical tb will never be used by differing targets (ignoring the case of different targets but same ISA). Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth