| Message ID | 20210920080451.408655-29-git@xen0n.name (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | 64-bit LoongArch port of QEMU TCG | expand |
On 9/20/21 1:04 AM, WANG Xuerui wrote: > Signed-off-by: WANG Xuerui <git@xen0n.name> > --- > configure | 4 +++- > meson.build | 4 +++- > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index 1043ccce4f..f1bc85e71b 100755 > --- a/configure > +++ b/configure > @@ -659,6 +659,8 @@ elif check_define __arm__ ; then > cpu="arm" > elif check_define __aarch64__ ; then > cpu="aarch64" > +elif check_define __loongarch64 ; then > + cpu="loongarch64" > else > cpu=$(uname -m) > fi > @@ -667,7 +669,7 @@ ARCH= > # Normalise host CPU name and set ARCH. > # Note that this case should only have supported host CPUs, not guests. > case "$cpu" in > - ppc|ppc64|s390x|sparc64|x32|riscv32|riscv64) > + ppc|ppc64|s390x|sparc64|x32|riscv32|riscv64|loongarch64) > ;; > ppc64le) > ARCH="ppc64" > diff --git a/meson.build b/meson.build > index 2711cbb789..fb3befead5 100644 > --- a/meson.build > +++ b/meson.build > @@ -57,7 +57,7 @@ python = import('python').find_installation() > > supported_oses = ['windows', 'freebsd', 'netbsd', 'openbsd', 'darwin', 'sunos', 'linux'] > supported_cpus = ['ppc', 'ppc64', 's390x', 'riscv32', 'riscv64', 'x86', 'x86_64', > - 'arm', 'aarch64', 'mips', 'mips64', 'sparc', 'sparc64'] > + 'arm', 'aarch64', 'loongarch64', 'mips', 'mips64', 'sparc', 'sparc64'] > > cpu = host_machine.cpu_family() > targetos = host_machine.system() > @@ -269,6 +269,8 @@ if not get_option('tcg').disabled() > tcg_arch = 's390' > elif config_host['ARCH'] in ['x86_64', 'x32'] > tcg_arch = 'i386' > + elif config_host['ARCH'] == 'loongarch64' > + tcg_arch = 'loongarch' Be consistent with loongarch or loongarch64 everywhere. If there's no loongarch32, and never will be, then there's probably no point in keeping the '64' suffix. r~
Hi Richard, On 9/21/21 01:23, Richard Henderson wrote: > On 9/20/21 1:04 AM, WANG Xuerui wrote: >> Signed-off-by: WANG Xuerui <git@xen0n.name> >> --- >> configure | 4 +++- >> meson.build | 4 +++- >> 2 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/configure b/configure >> index 1043ccce4f..f1bc85e71b 100755 >> --- a/configure >> +++ b/configure >> @@ -659,6 +659,8 @@ elif check_define __arm__ ; then >> cpu="arm" >> elif check_define __aarch64__ ; then >> cpu="aarch64" >> +elif check_define __loongarch64 ; then >> + cpu="loongarch64" >> else >> cpu=$(uname -m) >> fi >> @@ -667,7 +669,7 @@ ARCH= >> # Normalise host CPU name and set ARCH. >> # Note that this case should only have supported host CPUs, not >> guests. >> case "$cpu" in >> - ppc|ppc64|s390x|sparc64|x32|riscv32|riscv64) >> + ppc|ppc64|s390x|sparc64|x32|riscv32|riscv64|loongarch64) >> ;; >> ppc64le) >> ARCH="ppc64" >> diff --git a/meson.build b/meson.build >> index 2711cbb789..fb3befead5 100644 >> --- a/meson.build >> +++ b/meson.build >> @@ -57,7 +57,7 @@ python = import('python').find_installation() >> supported_oses = ['windows', 'freebsd', 'netbsd', 'openbsd', >> 'darwin', 'sunos', 'linux'] >> supported_cpus = ['ppc', 'ppc64', 's390x', 'riscv32', 'riscv64', >> 'x86', 'x86_64', >> - 'arm', 'aarch64', 'mips', 'mips64', 'sparc', 'sparc64'] >> + 'arm', 'aarch64', 'loongarch64', 'mips', 'mips64', 'sparc', >> 'sparc64'] >> cpu = host_machine.cpu_family() >> targetos = host_machine.system() >> @@ -269,6 +269,8 @@ if not get_option('tcg').disabled() >> tcg_arch = 's390' >> elif config_host['ARCH'] in ['x86_64', 'x32'] >> tcg_arch = 'i386' >> + elif config_host['ARCH'] == 'loongarch64' >> + tcg_arch = 'loongarch' > > Be consistent with loongarch or loongarch64 everywhere. > > If there's no loongarch32, and never will be, then there's probably no > point in keeping the '64' suffix. The loongarch32 tuple will most certainly come into existence some time in the future, but probably bare-metal-only and without a Linux port AFAIK. That's a point the Loongson people and I didn't communicate well, apologizes for that. (While we're at it, the reserved "loongarchx32" which is x32/n32-like, most likely will never exist.) So should I drop the explicit probing for __loongarch64, instead just probe for __loongarch__ and later #error out the non-__loongarch64 cases individually? > > > r~
On 9/21/21 08:02, WANG Xuerui wrote: > On 9/21/21 01:23, Richard Henderson wrote: >> On 9/20/21 1:04 AM, WANG Xuerui wrote: >>> Signed-off-by: WANG Xuerui <git@xen0n.name> >>> --- >>> configure | 4 +++- >>> meson.build | 4 +++- >>> 2 files changed, 6 insertions(+), 2 deletions(-) >> If there's no loongarch32, and never will be, then there's probably no >> point in keeping the '64' suffix. > > The loongarch32 tuple will most certainly come into existence some time > in the future, but probably bare-metal-only and without a Linux port > AFAIK. That's a point the Loongson people and I didn't communicate well, > apologizes for that. (While we're at it, the reserved "loongarchx32" > which is x32/n32-like, most likely will never exist.) Are you trying to beat MIPS at their ABI complexity? /s
Hi Philippe, On 9/21/21 14:59, Philippe Mathieu-Daudé wrote: > On 9/21/21 08:02, WANG Xuerui wrote: >> On 9/21/21 01:23, Richard Henderson wrote: >>> On 9/20/21 1:04 AM, WANG Xuerui wrote: >>>> Signed-off-by: WANG Xuerui <git@xen0n.name> >>>> --- >>>> configure | 4 +++- >>>> meson.build | 4 +++- >>>> 2 files changed, 6 insertions(+), 2 deletions(-) > >>> If there's no loongarch32, and never will be, then there's probably >>> no point in keeping the '64' suffix. >> >> The loongarch32 tuple will most certainly come into existence some >> time in the future, but probably bare-metal-only and without a Linux >> port AFAIK. That's a point the Loongson people and I didn't >> communicate well, apologizes for that. (While we're at it, the >> reserved "loongarchx32" which is x32/n32-like, most likely will never >> exist.) > > Are you trying to beat MIPS at their ABI complexity? /s Hah, I'm not Loongson employee so maybe I'm not in the best position to answer this ;-) But from an outsider's perspective, the Loongson people obviously reserved things upfront like a multi-millionaire, then suddenly realized they only have ~500 people on board, developers even less; so they did the Right Thing(TM), only later, to drop x32 altogether and focus their energy on bare-metal use cases for their 32-bit-only chips. Plus, LoongArch is strictly little-endian, and only one baseline ISA revision is published so far, so IMO it can never beat MIPS in terms of combinatorial ABI possibilities. Maybe RISC-V have a chance? ;-)
On 9/20/21 11:02 PM, WANG Xuerui wrote: > The loongarch32 tuple will most certainly come into existence some time in the future, but > probably bare-metal-only and without a Linux port AFAIK. Ok, I'll bear that in mind when considering target/loongarch/. > So should I drop the explicit probing for __loongarch64, instead just probe for > __loongarch__ and later #error out the non-__loongarch64 cases individually? I'm ok with checking the __loongarch64 define, but I thing ARCH=loongarch is sufficient. That name will apply to linux-user/host/$ARCH/ and tcg/$ARCH/. r~
Hi Richard, On 9/21/21 21:30, Richard Henderson wrote: > On 9/20/21 11:02 PM, WANG Xuerui wrote: > >> So should I drop the explicit probing for __loongarch64, instead just >> probe for __loongarch__ and later #error out the non-__loongarch64 >> cases individually? > > I'm ok with checking the __loongarch64 define, but I thing > ARCH=loongarch is sufficient. That name will apply to > linux-user/host/$ARCH/ and tcg/$ARCH/. > I just dug deeper into this while waiting for compilations; indeed the cpu variable must be "loongarch64" but ARCH could be just "loongarch". The $cpu is shoved directly into the meson cross file as CPU family name, for which only "loongarch64" is valid [1]. I'll keep probing for __loongarch64 but just transform the ARCH value. [1]: https://mesonbuild.com/Reference-tables.html#cpu-families
On 9/21/21 22:07, WANG Xuerui wrote: > Hi Richard, > > On 9/21/21 21:30, Richard Henderson wrote: >> On 9/20/21 11:02 PM, WANG Xuerui wrote: >> >>> So should I drop the explicit probing for __loongarch64, instead >>> just probe for __loongarch__ and later #error out the >>> non-__loongarch64 cases individually? >> >> I'm ok with checking the __loongarch64 define, but I thing >> ARCH=loongarch is sufficient. That name will apply to >> linux-user/host/$ARCH/ and tcg/$ARCH/. >> > I just dug deeper into this while waiting for compilations; indeed the > cpu variable must be "loongarch64" but ARCH could be just "loongarch". > The $cpu is shoved directly into the meson cross file as CPU family > name, for which only "loongarch64" is valid [1]. I'll keep probing for > __loongarch64 but just transform the ARCH value. > Ah wait, it seems the used value is $ARCH... But some changes around the $cpu/$ARCH handling are necessary anyway. Sorry for the noise! > [1]: https://mesonbuild.com/Reference-tables.html#cpu-families > > >
On Mon, 20 Sept 2021 at 18:25, Richard Henderson <richard.henderson@linaro.org> wrote: > > On 9/20/21 1:04 AM, WANG Xuerui wrote: > > Signed-off-by: WANG Xuerui <git@xen0n.name> > Be consistent with loongarch or loongarch64 everywhere. > > If there's no loongarch32, and never will be, then there's probably no point in keeping > the '64' suffix. What does Linux 'uname -m' call the architecture, and what is the name in the gcc triplet? Generally I think we should prefer to follow those precedents (which hopefully don't point in different directions) rather than making up our own architecture names. thanks -- PMM
On 9/21/21 7:42 AM, Peter Maydell wrote: > On Mon, 20 Sept 2021 at 18:25, Richard Henderson > <richard.henderson@linaro.org> wrote: >> >> On 9/20/21 1:04 AM, WANG Xuerui wrote: >>> Signed-off-by: WANG Xuerui <git@xen0n.name> > >> Be consistent with loongarch or loongarch64 everywhere. >> >> If there's no loongarch32, and never will be, then there's probably no point in keeping >> the '64' suffix. > > What does Linux 'uname -m' call the architecture, and what is the > name in the gcc triplet? The kernel will report arch/loongarch/Makefile:UTS_MACHINE := loongarch64 and it appears that the toolchain is using loongarch64 as well. So, Xuerui, I think there's your answer... r~
Hi Peter, On 9/21/21 22:42, Peter Maydell wrote: > On Mon, 20 Sept 2021 at 18:25, Richard Henderson > <richard.henderson@linaro.org> wrote: >> On 9/20/21 1:04 AM, WANG Xuerui wrote: >>> Signed-off-by: WANG Xuerui <git@xen0n.name> >> Be consistent with loongarch or loongarch64 everywhere. >> >> If there's no loongarch32, and never will be, then there's probably no point in keeping >> the '64' suffix. > What does Linux 'uname -m' call the architecture, and what is the > name in the gcc triplet? Generally I think we should prefer to follow > those precedents (which hopefully don't point in different directions) > rather than making up our own architecture names. uname -m says "loongarch64", the GNU triple arch name is also "loongarch64". I'd say it's similar to the situation of RISC-V or MIPS; except that a Linux port to the 32-bit variant of LoongArch might not happen, precluding a QEMU port. I think cpu=loongarch64 but ARCH=loongarch should be okay; at least it's better than, say, the Go language or Gentoo, where this architecture is named "loong64" and "loong"; or the binutils internals where it's "larch". > > thanks > -- PMM
On 9/21/21 9:09 AM, WANG Xuerui wrote:
> I think cpu=loongarch64 but ARCH=loongarch should be okay...
Make it easier on yourself and keep them the same.
r~
diff --git a/configure b/configure index 1043ccce4f..f1bc85e71b 100755 --- a/configure +++ b/configure @@ -659,6 +659,8 @@ elif check_define __arm__ ; then cpu="arm" elif check_define __aarch64__ ; then cpu="aarch64" +elif check_define __loongarch64 ; then + cpu="loongarch64" else cpu=$(uname -m) fi @@ -667,7 +669,7 @@ ARCH= # Normalise host CPU name and set ARCH. # Note that this case should only have supported host CPUs, not guests. case "$cpu" in - ppc|ppc64|s390x|sparc64|x32|riscv32|riscv64) + ppc|ppc64|s390x|sparc64|x32|riscv32|riscv64|loongarch64) ;; ppc64le) ARCH="ppc64" diff --git a/meson.build b/meson.build index 2711cbb789..fb3befead5 100644 --- a/meson.build +++ b/meson.build @@ -57,7 +57,7 @@ python = import('python').find_installation() supported_oses = ['windows', 'freebsd', 'netbsd', 'openbsd', 'darwin', 'sunos', 'linux'] supported_cpus = ['ppc', 'ppc64', 's390x', 'riscv32', 'riscv64', 'x86', 'x86_64', - 'arm', 'aarch64', 'mips', 'mips64', 'sparc', 'sparc64'] + 'arm', 'aarch64', 'loongarch64', 'mips', 'mips64', 'sparc', 'sparc64'] cpu = host_machine.cpu_family() targetos = host_machine.system() @@ -269,6 +269,8 @@ if not get_option('tcg').disabled() tcg_arch = 's390' elif config_host['ARCH'] in ['x86_64', 'x32'] tcg_arch = 'i386' + elif config_host['ARCH'] == 'loongarch64' + tcg_arch = 'loongarch' elif config_host['ARCH'] == 'ppc64' tcg_arch = 'ppc' elif config_host['ARCH'] in ['riscv32', 'riscv64']
Signed-off-by: WANG Xuerui <git@xen0n.name> --- configure | 4 +++- meson.build | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-)