[Qemu-devel] Removal of some target CPU macros

[Qemu-devel] Removal of some target CPU macros

[Fabrice Bellard]

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 ?

Regards,

Fabrice.

Re: [Qemu-devel] Removal of some target CPU macros

[Jocelyn Mayer]

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.

The PowerPC 64 with hypervisor mode support could be removed only if:
- the fact of emulating hypervisor feature do not slowdown the emulator
(which I greatly doubt, but there may be great surprises)
- 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.

Re: [Qemu-devel] Removal of some target CPU macros

[Fabrice Bellard]

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.

> The PowerPC 64 with hypervisor mode support could be removed only if:
> - the fact of emulating hypervisor feature do not slowdown the emulator
> (which I greatly doubt, but there may be great surprises)

I greatly doubt too.

> - 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.

Fabrice.

Re: [Qemu-devel] Removal of some target CPU macros

[J. Mayer]

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.

[...]
> > - 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.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Removal of some target CPU macros

[Thiemo Seufer]

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.

I used both in combination to avoid unintended differences in CPU
behaviour. I agree it is somewhat ugly, and ABI specific defines
would be better. I will make a patch when I find time for it.


Thiemo

Re: [Qemu-devel] Removal of some target CPU macros

[Fabrice Bellard]

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.

Re: [Qemu-devel] Removal of some target CPU macros

[J. Mayer]

On Wed, 2007-11-07 at 22:47 +0000, Paul Brook wrote:
> > 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.
> 
> ICBW, but it looks like it should be fairly straightforward to replace 
> TARGET_PPC64H with a runtime check. The only really significant overhead I 
> can see is having to flush an extra set of TLBs, and I guess there are ways 
> round that if it is a problem.

I can check the hypervisor feature is not present, for emulating PowerPC
620 on a target that would have hypervisor emulation support. But I
cannot do as if the CPU do not have the feature if it's actually
available. The PowerPC 64 target emulates PowerPC 64 without the
hypervisor feature, which actually do not exist but looks like a G5
machine when running Linux on it. If the emulator has the hypervisor
feature enabled, I need an hypervisor software to boot and manage the
machine (trap the hypervisor exception, update or emulate the registers
the OS is not allowed to access anymore, ...), which I don't have, then
I would not be able to do any test or run any OS on this emulated target
(you could argue that I  do not have it to test the ppc64h target too,
which is true...). There is nothing in the CPU that would allow me to
make it run "as if the hypervisor mode do not exists". Then I do not
have anything to check. The only possible runtime solution would be to
duplicate every defined 64 bits CPU to define one model supporting
hypervisor feature and another acting as this feature do not exist (the
register definitions / access rights are not the same, and are defined
at CPU instanciation time, adding run-time checks there would cost a
lot...) and hope run-time checks won't cost too much. I don't think this
solution is cleaner than having a separate target, it would bring
confusion for the user imho, and it does not seem easier to test.

> I can see why you want CPUs with and without hypervisor mode, I'm just not 
> convinced it needs a separate qemu binary.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Removal of some target CPU macros

[Bernhard Fischer]

On Wed, Nov 07, 2007 at 11:55:26PM +0100, Fabrice Bellard wrote:

>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.

IMHO same for i386sx. Without an FPU there is just no FPU. Without
486-specific instructions (or i586 etc. for that matter), the machine is
just constrained to the one requested by the user.

The fact that usually too many non ISA-imposed features are available
without explicit user choice is very, very unfortunate, IMO.
As always, features are or may be nice, iff and only if you are not
forced to have or use them..

Re: [Qemu-devel] Removal of some target CPU macros

[Paul Brook]

On Wednesday 07 November 2007, Bernhard Fischer wrote:
> On Wed, Nov 07, 2007 at 11:55:26PM +0100, Fabrice Bellard wrote:
> >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.
>
> IMHO same for i386sx. Without an FPU there is just no FPU. Without
> 486-specific instructions (or i586 etc. for that matter), the machine is
> just constrained to the one requested by the user.
>
> The fact that usually too many non ISA-imposed features are available
> without explicit user choice is very, very unfortunate, IMO.
> As always, features are or may be nice, iff and only if you are not
> forced to have or use them..

The i386 emulation always enables all features because noone's bothered to 
teach it which ones are optional.

I have local ARM patches (hopefully will be merged into CVS soon) that 
implement 5+ different ISA variants, 3 different FPUs, a SIMD vector unit and 
2 completely different exception models. All in the same binary, and all of 
which can be turned off if for emulating cpus that don't implement a 
particular feature.

Paul

Re: [Qemu-devel] Removal of some target CPU macros

[Paul Brook]

> I can check the hypervisor feature is not present, for emulating PowerPC
> 620 on a target that would have hypervisor emulation support. But I
> cannot do as if the CPU do not have the feature if it's actually
> available. The PowerPC 64 target emulates PowerPC 64 without the
> hypervisor feature, which actually do not exist but looks like a G5
> machine when running Linux on it. If the emulator has the hypervisor
> feature enabled, I need an hypervisor software to boot and manage the
> machine

I agree with this much.

>  There is nothing in the CPU that would allow me to
> make it run "as if the hypervisor mode do not exists".

So add one. It obviously exists conceptually, because that's what the 
non-hypervisor qemu emulates.

> The only possible runtime solution would be to
> duplicate every defined 64 bits CPU to define one model supporting
> hypervisor feature and another acting as this feature do not exist (the
> register definitions / access rights are not the same, and are defined
> at CPU instanciation time, adding run-time checks there would cost a
> lot...) and hope run-time checks won't cost too much.

As I mentioned earlier, from looking at all the occurrences of TARGET_PPC64H 
I'd expect the runtime overhead to be minimal, if it's measurable at all.

I'm not sure what you're getting at about flags being defined at instantiation 
time. That's the same whether you have two binaries or one.

Duplicating the CPU definitions should also be fairly trivial. You're 
effectively already doing it when you build the separate ppc64 and ppc64h 
binaries. I find it hard to believe it would be hard to do the same 
transformation at runtime.

Paul

Re: [Qemu-devel] Removal of some target CPU macros

[Tristan Gingold]

Two side comments:

> 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.

Has anyone started to implement spe ?

> - 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.

Does xen/ppc satisfy your requirement ?
Maybe Hollis will comment.

Re: [Qemu-devel] Removal of some target CPU macros

[J. Mayer]

On Thu, 2007-11-08 at 14:09 +0100, Tristan Gingold wrote:
> Two side comments:

Hi,

> > 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.
> 
> Has anyone started to implement spe ?

Large parts of the SPE extensions are implemented, most fixed-point
operations (but the multiply and add family) and I think almost all
floating-point operations (the flags are not properly emulated, for
now). But there's a lack of a CPU model that would really use it. It
could be made available very easily for a test CPU for user-mode only,
as it is now. The MMU model used on Freescale cores is not implemented
yet, then the full-system emulation would not be possible for now.

> > - 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.
> 
> Does xen/ppc satisfy your requirement ?
> Maybe Hollis will comment.

I don't know really. I guess it may do for the more urgent need which is
to have a  fully "transparent" hypervisor that would enable the OS to
access all resources. I won't bet it could be a replacement for IBM
hypervisor software as the full specifications of this software have
still not be fully released (the PPAR document, which describes the
whole hypervisor features is still a draft).
But it's a good idea, I may take a look of what it could provide.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Removal of some target CPU macros

[J. Mayer]

On Wed, 2007-11-07 at 23:37 +0000, Paul Brook wrote:
> > I can check the hypervisor feature is not present, for emulating PowerPC
> > 620 on a target that would have hypervisor emulation support. But I
> > cannot do as if the CPU do not have the feature if it's actually
> > available. The PowerPC 64 target emulates PowerPC 64 without the
> > hypervisor feature, which actually do not exist but looks like a G5
> > machine when running Linux on it. If the emulator has the hypervisor
> > feature enabled, I need an hypervisor software to boot and manage the
> > machine
> 
> I agree with this much.
> 
> >  There is nothing in the CPU that would allow me to
> > make it run "as if the hypervisor mode do not exists".
> 
> So add one. It obviously exists conceptually, because that's what the 
> non-hypervisor qemu emulates.

I admit you're right, here... Maybe just disabling the "hypervisor mode"
flags and cleaverly initialise all hypervisor specific registers could
make it act like the current PowerPC 64 target but this is to be checked
when all hypervisor features will be emulated.

> > The only possible runtime solution would be to
> > duplicate every defined 64 bits CPU to define one model supporting
> > hypervisor feature and another acting as this feature do not exist (the
> > register definitions / access rights are not the same, and are defined
> > at CPU instanciation time, adding run-time checks there would cost a
> > lot...) and hope run-time checks won't cost too much.
> 
> As I mentioned earlier, from looking at all the occurrences of TARGET_PPC64H 
> I'd expect the runtime overhead to be minimal, if it's measurable at all.

Maybe because there are a lot of things missing for the hypervisor
feature to be completelly emulated... All the MMU part, specific
registers, ..., is missing.

> I'm not sure what you're getting at about flags being defined at instantiation 
> time. That's the same whether you have two binaries or one.

True.

> Duplicating the CPU definitions should also be fairly trivial. You're 
> effectively already doing it when you build the separate ppc64 and ppc64h 
> binaries. I find it hard to believe it would be hard to do the same 
> transformation at runtime.

Yes, it's trivial to duplicate the CPU definitions. I'm just afraid of
the confusion it could introduce for the user seeing two definitions of
the same CPU.

-- 
J. Mayer <l_indien@magic.fr>
Never organized