J. Mayer wrote: > On Wed, 2007-11-07 at 22:55 +0100, Fabrice Bellard wrote: >> Jocelyn Mayer wrote: >>> On Wed, 2007-11-07 at 19:32 +0100, Fabrice Bellard wrote: >>>> I noticed that some target CPUs macros have been added while they do not >>>> seem necessary. I don't like that because it introduces more #ifdefs >>>> which prevent making a version supporting simultaneously all the CPUs. >>>> >>>> In particular I saw the following: >>>> >>>> - TARGET_MIPSN32 : it is always combined with TARGET_MIPS64 in >>>> target-mips/. If its only usage is to select a different Linux ABI, then >>>> I suggest keeping TARGET_MIPS64 and using another define to choose that. >>>> >>>> - TARGET_PPC64H, TARGET_PPCEMB : I see no reason why they cannot be >>>> handled dynamically as the other PowerPC CPU types, provided that >>>> TARGET_PPC64 is defined. Is it the long term plan ? >>> PowerPC embedded models are already available (should say should be as >>> none are actually implemented) when PPC64 is defined. But as those are >>> mainly PowerPC 32 with some extensions to manipulate the 64 bits GPR, >>> it's a great help if we can avoid doing all operations in 64 bits when >>> running on a 32 bits host (which would greatly decrease performances by >>> at least a factor of two, which is not acceptable). Then having a >>> specific 32 bits target using 64 bits register is very useful if one >>> want to use those features, but may be disabled if the host is 64 bits. >>> Note that most (all ?) embedded Freescale PowerPC microcontrollers >>> implement those extensions and that some ones are greatly interrested >>> with having an usable emulation avaible for those CPUs. >> OK for the speed gain, but such features make the code more difficult to >> test because there are a lot of possible combinations. I'd say the same >> about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU. > > I got no choice here, as the 64 bits extensions of those CPUs uses the > GPR for computations. And the programs are supposed not to take any care > of the higher 32 bits when not using those extensions. I cannot make > them 64 bits for all PowerPC targets and those CPU are not PowerPC 64 > ones, so they do not match neither the PowerPC target, neither the > PowerPC 64 one.
You have the choice to emulate SPE extensions only in the TARGET_PPC64 case. As you said it is slower, but you avoid ifdefs. My last remark : "I'd say the same about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU." was unrelated to the SPE case. You have also the choice here to always force it to 32 bit. > [...] >>> - someone provide an open-source hypervisor, compatible with the ones >>> used on real machines, that would allow at least Linux to be able to run >>> on a CPU with hypervisor mode available. Most 64 bits PowerPC, including >>> the 970 (ie G5) have the hypervisor mode support implemented. If the >>> hypervisor mode emulation is present, the OS won't be allowed to access >>> most SPR and some exceptions will need to have some specific handlers in >>> the hypervisor firmware. As I don't know such a software available, the >>> hypervisor mode can not be enabled for "standard" PowerPC 64 emulation; >>> or no-one will be able to actually use the emulator, except if using the >>> venerable but mostly undocumented (and nearly impossible to find on real >>> hardware) PowerPC 620 CPU. >>> Furthermore, running (or emulating) a SMP machine on a 64 bits PowerPC >>> with hypervisor features without hypervisor software is exactly >>> impossible. >>> Then I don't see how we can do without a separated target for hypervisor >>> features support. >> What you say does not justify the separate ppc64h target : it just >> implies that you need to add a separate machine to make hypervisor tests. > > There is no documented way to disable the hypervisor feature on 64 bits > PowerPC CPUs, even if the Apple SMU is said to do this before the CPU > boots (but there is no known way to check if it's true). Then, it will > make all PowerPC 64 emulated (but the 602) unusable as there'll be no > known OSS to manage them. > Removing the ppc64h target means, for me, removing any option to emulate > the hypervisor feature at any time (if removed) or removing the ability > to use the PowerPC 64 targets the way they are when booting on Apple G5 > machines (if merged with the ppc64 target). None of those options seem > acceptable to me. Why not adding a new CPU type such as "PPC970 with hypervisor" and keep the current PPC970 implementation as it is without the hypervisor mode. I don't see the problem in replacing the ifdefs with a new CPU model ! You cannot reasonnably tell that it is uglier than the current code. Fabrice.
