Re: Bug#980963: dpkg: Please add ARC architecture
On 3/4/21 3:56 PM, Vineet Gupta wrote:
>> Also just to make sure, the GNU triplets are:
>>
>> arc-linux-gnu
>> arceb-linux-gnu
>> No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right?
>
> Actually it seems we are missing hardfloat here: ARC glibc/gcc support
> it very well and should be default for any reasonable performance.
>
> So I think we should add
> arc-linux-gnuhf
> arceb-linux-gnuhf
>
> BTW I have oce question: where does one select what default toggles to
> build the entire software stack with (say -mcpu etc). Does this rely
> on toolchain driver default to DRTH. One of my problems with
> rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it
> there (and planning to upstream the gcc driver patch).
So here's the lay of the land, apologies for the long email, and if
some/most of below is not directly relevant to dpkg bug, but I'll
provide the background so we are all on same page.
We've had 3 revisions of the ISA and ensuing multiple processors in last
15 years:
ISA Implementations/Processors (Linux capable)
------ ---------------------------------------------------------------
ARCompact ARC700
ARCv2 HS38x/HS48x
ARCv3:32-bit HS58MP
ARCv3:64-bit HS68MP
- ARCompact is legacy and no new development needed including debian port.
- Code for one ISA is not compatible with priors, mainly due to addition
of new instructions. In fact given the configurability of the ISA itself
(for better or worse), one could end up 2 non-compatible variants of
same ISA (think double load/store instructions in ARCv2). But the port
can assume the all encompassing super-set of the ISA as baseline.
- ARCv3 is currently under development / pre-production but should be
kept in mind as it is knocking on the door already.
In terms of the ABI critical flavors: there's little/big endian and
soft/hard-float.
- Again big endian debian is not needed - mainly because of number of
customer engagements and resourcing needed to support it
- ARCv2 hard-float ABI is same as soft - FPU shares the same register
file so the calling conventions are same. However the triplet is
different arc-linux-gnuhf [1] as libraries for hard won't run on a
soft-float system due to lack of emulation etc.
- ARCv3 does have a dedicated FP register file so there's soft and hard ABIs
So given all of this, I'd like to propose ARCv2 port with hard-float as
baseline. We don't bother with Big-endian. A soft-float would be
desirable for debugging and fall-back but not necessary from feature pov.
I'm open to port names as maintainers feel appropriate - but stick with
current triplets arc-gnu-linux / arc-gnu-linuxhf for ARCv2.
For ARCv3, we could have arc64* / arc32*
Please let me know if this makes sense.
Once we agree, we can start off with requesting changes to GNU config
project.
Thx,
-Vineet
[1] I don't see the arc hf explicitly @
https://git.savannah.gnu.org/cgit/config.git/tree/testsuite/config-sub.data
Reply to: