ARC: Add support for ARC HS38 with Hardware Floating Point
PATCH 1/1 ARC: Add support for ARC HS38 with Hardware Floating Point
--- arch/Config.in.arc | 10 +++++++--- package/uclibc/Config.in | 1 + 2 files changed, 8 insertions(+), 3 deletions(-)
arch/Config.in.arc +7 -3
@@ -14,12 +14,15 @@ config BR2_arc770d config BR2_archs38 bool "ARC HS38" +config BR2_archs38_hf + bool "ARC HS38 with hard floating-point" + endchoice # Choice of atomic instructions presence config BR2_ARC_ATOMIC_EXT bool "Atomic extension (LLOCK/SCOND instructions)" - default y if BR2_arc770d || BR2_archs38 + default y if BR2_arc770d || BR2_archs38 || BR2_archs38_hf config BR2_ARCH default "arc" if BR2_arcle
@@ -37,6 +40,7 @@ config BR2_GCC_TARGET_CPU default "arc700" if BR2_arc750d default "arc700" if BR2_arc770d default "archs" if BR2_archs38 + default "hs38_linux" if BR2_archs38_hf choice prompt "MMU Page Size"
@@ -56,7 +60,7 @@ choice config BR2_ARC_PAGE_SIZE_4K bool "4KB" - depends on BR2_arc770d || BR2_archs38 + depends on BR2_arc770d || BR2_archs38 || BR2_archs38_hf config BR2_ARC_PAGE_SIZE_8K bool "8KB"
@@ -66,7 +70,7 @@ config BR2_ARC_PAGE_SIZE_8K config BR2_ARC_PAGE_SIZE_16K bool "16KB" - depends on BR2_arc770d || BR2_archs38 + depends on BR2_arc770d || BR2_archs38 || BR2_archs38_hf endchoice
package/uclibc/Config.in +1 -0
@@ -134,6 +134,7 @@ config BR2_UCLIBC_ARC_TYPE default "ARC_CPU_700" if BR2_arc750d default "ARC_CPU_700" if BR2_arc770d default "ARC_CPU_HS" if BR2_archs38 + default "ARC_CPU_HS" if BR2_archs38_hf config BR2_UCLIBC_MIPS_ABI string
Signature · 1 line
2.11.0
PATCH 1/1 ARC: Add support for ARC HS38 with Hardware Floating Point
Hello,
Quoted 11 lines · Alexey Brodkin
Signed-off-by Alexey Brodkin <[email protected]>--- arch/Config.in.arc | 10 +++++++--- package/uclibc/Config.in | 1 + 2 files changed, 8 insertions(+), 3 deletions(-)arch/Config.in.arc +0
-0
arch/Config.in.arc config BR2_arc770d · line 18
Quoted 5 lines
arch/Config.in.arc +2
-0@@ -14,12 +14,15 @@ config BR2_arc770d config BR2_archs38 bool "ARC HS38" +config BR2_archs38_hf + bool "ARC HS38 with hard floating-point"
Does it need to be a separate CPU type, or an option when HS38 is selected ?
arch/Config.in.arc config BR2_GCC_TARGET_CPU · line 43
Quoted 7 lines
arch/Config.in.arc +1
-0config BR2_ARCH default "arc" if BR2_arcle@@ -37,6 +40,7 @@ config BR2_GCC_TARGET_CPU default "arc700" if BR2_arc750d default "arc700" if BR2_arc770d default "archs" if BR2_archs38 + default "hs38_linux" if BR2_archs38_hf
gcc really understands -mcpu=hs38_linux ?
It seems odd to have the operating system name encoded in the CPU name.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 ARC: Add support for ARC HS38 with Hardware Floating Point
Hi Thomas,
Quoted 10 lines · Thomas Petazzoni
Hello,
Quoted 7 lines · Alexey Brodkin
Signed-off-by Alexey Brodkin <[email protected]>---
?arch/Config.in.arc???????| 10 +++++++---
?package/uclibc/Config.in |??1 +
?2 files changed, 8 insertions(+), 3 deletions(-)
Quoted 13 lines
arch/Config.in.arc config BR2_arc770d · line 18
Quoted 10 lines
arch/Config.in.arc +0
-0@@ -14,12 +14,15 @@ config BR2_arc770d?config
BR2_archs38
? bool "ARC HS38"
?arch/Config.in.arc +2
-0+config BR2_archs38_hf + bool "ARC HS38 with hard floating-point"Does it need to be a separate CPU type, or an option when HS38 is selected ?
Well this is a real "-mcpu" value understood by GCC for ARC ------------------------------>8------------------------------- arc-linux-gcc --target-help
...
ARC-specific assembler options:
? -mcpu=<cpu name> ??(default: hs38), assemble for CPU <cpu name>, one of:
??????????????????????????arc700, nps400, arcem, em, em4, em4_dmips, em4_fpus,? ??????????????????????????em4_fpuda, quarkse_em, archs, hs, hs34, hs38,? ??????????????????????????hs38_linux, arc600, arc600_norm, arc600_mul64,? ??????????????????????????arc600_mul32x16, arc601, arc601_norm, arc601_mul64,? ??????????????????????????arc601_mul32x16 ------------------------------>8-------------------------------
And in itself this is pretty much an alias to a set of HW features selected by default in the same ARC HS38 "template" in CPU configuration utility. In fact it is "-mcpu=hs38 -mfpu=fpud_all". But when we configure GCC with "-mcpu" option it then is used by default, i.e. even if we later build a random application with a simple "arc-linux-gcc test.c" it implicitly gets optimized for that same "-mcpu"... i.e. there's no need in adding stuff in TARGET_ABI variable in Buildroot etc.
For example in OpenEmbedded we went via separate options instead of those "templates" as the same toolchain is reused between different builds which differs from Buildroot where we build everything for just one HW configuration. So IMHO templates approach in Buildroot is more convenient.
Quoted 11 lines
?config
BR2_ARCHarch/Config.in.arc
Quoted 6 lines
? default "arc" if
BR2_arclearch/Config.in.arc +0
-0@@ -37,6 +40,7 @@ config BR2_GCC_TARGET_CPU? default "arc700" if
BR2_arc750d
? default "arc700" ifBR2_arc770d
? default "archs" ?ifBR2_archs38arch/Config.in.arc +1
-0+ default "hs38_linux" ?if BR2_archs38_hfgcc really understands -mcpu=hs38_linux ?
It seems odd to have the operating system name encoded in the CPU name.
The rationale behind that naming was to highlight a template which is the best option for Linux use-case. I.e. if you want to build a system that runs
Linux on top of ARC HS38 core please consider usage of that "template" which has HW features that [may significantly] improve performance of the system.
Still not sure if now you feel more comfortable with that stuff :))
-Alexey
PATCH 1/1 ARC: Add support for ARC HS38 with Hardware Floating Point
Finally coming back to this old patch...
Quoted 40 lines · Alexey Brodkin
Hi Thomas,
Quoted 10 lines · Thomas Petazzoni
Hello,
Quoted 7 lines · Alexey Brodkin
Signed-off-by Alexey Brodkin <[email protected]>---
?arch/Config.in.arc???????| 10 +++++++---
?package/uclibc/Config.in |??1 +
?2 files changed, 8 insertions(+), 3 deletions(-)Quoted 13 lines
arch/Config.in.arc config BR2_arc770d · line 18
Quoted 10 lines
arch/Config.in.arc +0
-0@@ -14,12 +14,15 @@ config BR2_arc770d?config
BR2_archs38
? bool "ARC HS38"
?arch/Config.in.arc +2
-0+config BR2_archs38_hf + bool "ARC HS38 with hard floating-point"Does it need to be a separate CPU type, or an option when HS38 is selected ?
Well this is a real "-mcpu" value understood by GCC for ARC ------------------------------>8------------------------------- arc-linux-gcc --target-help
...
ARC-specific assembler options:
? -mcpu=<cpu name> ??(default: hs38), assemble for CPU <cpu name>, one of:
??????????????????????????arc700, nps400, arcem, em, em4,em4_dmips,em4_fpus,? ??????????????????????????em4_fpuda,quarkse_em, archs, hs, hs34, hs38,? ??????????????????????????hs38_linux, arc600,arc600_norm,arc600_mul64,? ??????????????????????????arc600_mul32x16, arc601,arc601_norm,arc601_mul64,? ??????????????????????????arc601_mul32x16 ------------------------------>8-------------------------------
Quoted 7 lines
And in itself this is pretty much an alias to a set of HW features selected by default in the same ARC HS38 "template" in CPU configuration utility. In fact it is "-mcpu=hs38 -mfpu=fpud_all". But when we configure GCC with "-mcpu" option it then is used by default, i.e. even if we later build a random application with a simple "arc-linux-gcc
test.c" it implicitly gets optimized for that same "-mcpu"... i.e. there's no need in adding stuff inTARGET_ABIvariable in Buildroot etc.
As such, I don't think this is a sufficient reason to make it a separate CPU
option. Rather, I think we should consider what are the likely future architectures that are going to be added. We now have 750d, 770d and hs38. I guess there is no floating point option for the 750d and 770d? If there is, then clearly it would be better to have a separate hf option so it can be used for the 750d and 770d as well. If not, we should consider a future hs42: is it likely to have an optional fpu? Or is it likely to always have an fpu?
Basically, what we want to avoid in the long run is to have many different
subarches which are basically different combinations of options.
So, in short: making a separate subarch for it is only warranted if you expect
this will be the only one with an optional FPU (or rather, where in practice an FPU is always there, because obviously on ARC anything is possible).
Regards,
Arnout
Quoted 33 lines
For example in OpenEmbedded we went via separate options instead of those "templates" as the same toolchain is reused between different builds which differs from Buildroot where we build everything for just one HW configuration. So IMHO templates approach in Buildroot is more convenient.
Quoted 11 lines
?config
BR2_ARCHarch/Config.in.arc
Quoted 6 lines
? default "arc" if
BR2_arclearch/Config.in.arc +0
-0@@ -37,6 +40,7 @@ config BR2_GCC_TARGET_CPU? default "arc700" if
BR2_arc750d
? default "arc700" ifBR2_arc770d
? default "archs" ?ifBR2_archs38arch/Config.in.arc +1
-0+ default "hs38_linux" ?if BR2_archs38_hfgcc really understands -mcpu=hs38_linux ?
It seems odd to have the operating system name encoded in the CPU name.
The rationale behind that naming was to highlight a template which is the best option for Linux use-case. I.e. if you want to build a system that runs
Linux on top of ARC HS38 core please consider usage of that "template" which has HW features that [may significantly] improve performance of the system.Still not sure if now you feel more comfortable with that stuff :))
-Alexey
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 ARC: Add support for ARC HS38 with Hardware Floating Point
Hi Arnout,
Quoted 51 lines · Arnout Vandecappelle
Finally coming back to this old patch...
Quoted 40 lines · Alexey Brodkin
Hi Thomas,
Quoted 18 lines · Thomas Petazzoni
Hello,
Quoted 15 lines · Alexey Brodkin
Signed-off-by Alexey Brodkin <[email protected]>--- arch/Config.in.arc | 10 +++++++--- package/uclibc/Config.in | 1 + 2 files changed, 8 insertions(+), 3 deletions(-)arch/Config.in.arc +0
-0@@ -14,12 +14,15 @@ config BR2_arc770d config BR2_archs38 bool "ARC HS38"Quoted 5 lines
arch/Config.in.arc config BR2_arc770d · line 18
Quoted 2 lines
arch/Config.in.arc +2
-0+config BR2_archs38_hf + bool "ARC HS38 with hard floating-point"Does it need to be a separate CPU type, or an option when HS38 is selected ?
Well this is a real "-mcpu" value understood by GCC for ARC ------------------------------>8------------------------------- arc-linux-gcc --target-help
...
ARC-specific assembler options:
-mcpu=<cpu name> (default: hs38), assemble for CPU <cpu name>, one of:arc700, nps400, arcem, em, em4, em4_dmips, em4_fpus, em4_fpuda, quarkse_em, archs, hs, hs34, hs38, hs38_linux, arc600, arc600_norm, arc600_mul64, arc600_mul32x16, arc601, arc601_norm, arc601_mul64, arc601_mul32x16------------------------------>8-------------------------------
Quoted 7 lines
And in itself this is pretty much an alias to a set of HW features selected by default in the same ARC HS38 "template" in CPU configuration utility. In fact it is "-mcpu=hs38 -mfpu=fpud_all". But when we configure GCC with "-mcpu" option it then is used by default, i.e. even if we later build a random application with a simple "arc-linux-gcc
test.c" it implicitly gets optimized for that same "-mcpu"... i.e. there's no need in adding stuff inTARGET_ABIvariable in Buildroot etc.
Quoted 7 lines
As such, I don't think this is a sufficient reason to make it a separate CPU
option. Rather, I think we should consider what are the likely future architectures that are going to be added. We now have 750d, 770d and hs38. I guess there is no floating point option for the 750d and 770d? If there is, then clearly it would be better to have a separate hf option so it can be used for the 750d and 770d as well. If not, we should consider a future hs42: is it likely to have an optional fpu? Or is it likely to always have an fpu?
Indeed in case of ARC it's possible to turn features on and off and it is applicable to HW FPU. That said it maps on a separate option very well.
Quoted 6 lines
Basically, what we want to avoid in the long run is to have many different
subarches which are basically different combinations of options.So, in short: making a separate subarch for it is only warranted if you expect
this will be the only one with an optional FPU (or rather, where in practice an FPU is always there, because obviously on ARC anything is possible).
That's all understood but another problem is we really want to build all target binaries with that option. Quite some time ago I fixed libgcc so it uses TARGET_CFLAGS, see [1] so we're almost there but still at least uclibc is not yet there - we discussed it at length back in the day but decision was made we'd better build uClibc with well-tested pre-defined options and as of today uClibc only respects either TARGET_ABI or whatever GCC uses implicitly according to how GCC was configured.
So my approach was a bit of a trick to make sure we build EVERYTHING with HW FPU support. Maybe indeed this should be solved the other way around: set/reset BR2_SOFT_FLOAT and patch uClibc such that depending on UCLIBC_HAS_FPU state we pass proper flags to the compiler.
[1] https://git.buildroot.org/buildroot/commit/?id=0fe633cdff66febadc50bab3e0af4b3be53811c8
-Alexey