public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* Defining a Super Specific uArch
@ 2021-01-12 22:45 squirvel voxbox
  2021-01-13  0:04 ` Chris Packham
  0 siblings, 1 reply; 3+ messages in thread
From: squirvel voxbox @ 2021-01-12 22:45 UTC (permalink / raw)
  To: crossgcc

Hi All,

I asked a fairly similar question over on the irc channel, and didn't get a
response, so I'm trying here.

Let's say I'm attempting to target a super specific CPU, (in this case a
RK3328, which is a 64bit armv8-a+crypto cpu). What would be the proper way
to define the cpu?

I am currently defining:
    target architecture: arm
    suffix to the arch-part: v8-a+crypto (according to gcc, the dash is
required to define v8-a)
    emit assembly for CPU: cortex-a53
    other items are set based on the sample aarch64-rpi3 configuration

But ct-ng build fails due to:
    "Invalid configuration `aarch64v8-a+crypto-RK3328-linux-gnu': more than
four components" (so more than 4 dashes according to the script source code)
or if I disable the vendor string (set to RK3328)
    "Invalid configuration `aarch64v8-a+crypto-linux-gnu': machine
`aarch64v8-a+crypto' not recognized"

In theory I could just add all the specific uarch flags to CFLAGS/LDFLAGS
such as -march=, but that feels rather hacky especially since there is an
arch suffix field.

Is the hacky way the way I should be defining this cpu, or am I just
specifying this incorrectly? If the latter, what is the proper way to
specify a super specific uarch?

Thanks,
squirvel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Defining a Super Specific uArch
  2021-01-12 22:45 Defining a Super Specific uArch squirvel voxbox
@ 2021-01-13  0:04 ` Chris Packham
  2021-01-13  4:41   ` squirvel voxbox
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Packham @ 2021-01-13  0:04 UTC (permalink / raw)
  To: squirvel voxbox, crossgcc


On 13/01/21 11:45 am, squirvel voxbox via crossgcc wrote:
> Hi All,
>
> I asked a fairly similar question over on the irc channel, and didn't get a
> response, so I'm trying here.
https://github.com/crosstool-ng/crosstool-ng is probably the best 
support channel these days. I keep an eye on IRC but it's sporadic at best.
> Let's say I'm attempting to target a super specific CPU, (in this case a
> RK3328, which is a 64bit armv8-a+crypto cpu). What would be the proper way
> to define the cpu?
My initial thought is to make a generic aarch64 toolchain and use 
-march= in CFLAGS to tune for your desired system (the 
aarch64-unknown-linux-gnu sample is probably good enough for this).
> I am currently defining:
>      target architecture: arm
>      suffix to the arch-part: v8-a+crypto (according to gcc, the dash is
> required to define v8-a)
The suffix is just used in naming the tools so it could be anything 
(often people add things "le", "be" or "hf"). Adding a '-' breaks things 
that use the toolchain tuple to figure stuff out. It'd be nice if we 
could stop users from putting a '-' in there but I'm not sure that 
Kconfig has a way of validating string input fields.
>      emit assembly for CPU: cortex-a53
>      other items are set based on the sample aarch64-rpi3 configuration
>
> But ct-ng build fails due to:
>      "Invalid configuration `aarch64v8-a+crypto-RK3328-linux-gnu': more than
> four components" (so more than 4 dashes according to the script source code)
> or if I disable the vendor string (set to RK3328)
>      "Invalid configuration `aarch64v8-a+crypto-linux-gnu': machine
> `aarch64v8-a+crypto' not recognized"
>
> In theory I could just add all the specific uarch flags to CFLAGS/LDFLAGS
> such as -march=, but that feels rather hacky especially since there is an
> arch suffix field.
I think what you want is to set CT_ARCH_ARCH ("Architecture level:") to 
armv8-a+crypto which should have the effect of making this the default 
when no -march= is specified in CFLAGS. The fact that you're already 
setting the vendor string to RK3328 is probably good enough to 
distinguish the resulting toolchain from any others you might have.
> Is the hacky way the way I should be defining this cpu, or am I just
> specifying this incorrectly? If the latter, what is the proper way to
> specify a super specific uarch?
>
> Thanks,
> squirvel
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Defining a Super Specific uArch
  2021-01-13  0:04 ` Chris Packham
@ 2021-01-13  4:41   ` squirvel voxbox
  0 siblings, 0 replies; 3+ messages in thread
From: squirvel voxbox @ 2021-01-13  4:41 UTC (permalink / raw)
  To: Chris Packham; +Cc: crossgcc

Thanks so much for the info, I was able to get my build running with it.

Very much was under the impression that the suffix was meant to define the
specific arch variant (ex POWER, with the suffix 8 or 9), rather than just
being the final name of the toolchain/config.

Cheers!

On Tue, Jan 12, 2021 at 7:04 PM Chris Packham <
Chris.Packham@alliedtelesis.co.nz> wrote:

>
> On 13/01/21 11:45 am, squirvel voxbox via crossgcc wrote:
> > Hi All,
> >
> > I asked a fairly similar question over on the irc channel, and didn't
> get a
> > response, so I'm trying here.
> https://github.com/crosstool-ng/crosstool-ng is probably the best
> support channel these days. I keep an eye on IRC but it's sporadic at best.
> > Let's say I'm attempting to target a super specific CPU, (in this case a
> > RK3328, which is a 64bit armv8-a+crypto cpu). What would be the proper
> way
> > to define the cpu?
> My initial thought is to make a generic aarch64 toolchain and use
> -march= in CFLAGS to tune for your desired system (the
> aarch64-unknown-linux-gnu sample is probably good enough for this).
> > I am currently defining:
> >      target architecture: arm
> >      suffix to the arch-part: v8-a+crypto (according to gcc, the dash is
> > required to define v8-a)
> The suffix is just used in naming the tools so it could be anything
> (often people add things "le", "be" or "hf"). Adding a '-' breaks things
> that use the toolchain tuple to figure stuff out. It'd be nice if we
> could stop users from putting a '-' in there but I'm not sure that
> Kconfig has a way of validating string input fields.
> >      emit assembly for CPU: cortex-a53
> >      other items are set based on the sample aarch64-rpi3 configuration
> >
> > But ct-ng build fails due to:
> >      "Invalid configuration `aarch64v8-a+crypto-RK3328-linux-gnu': more
> than
> > four components" (so more than 4 dashes according to the script source
> code)
> > or if I disable the vendor string (set to RK3328)
> >      "Invalid configuration `aarch64v8-a+crypto-linux-gnu': machine
> > `aarch64v8-a+crypto' not recognized"
> >
> > In theory I could just add all the specific uarch flags to CFLAGS/LDFLAGS
> > such as -march=, but that feels rather hacky especially since there is an
> > arch suffix field.
> I think what you want is to set CT_ARCH_ARCH ("Architecture level:") to
> armv8-a+crypto which should have the effect of making this the default
> when no -march= is specified in CFLAGS. The fact that you're already
> setting the vendor string to RK3328 is probably good enough to
> distinguish the resulting toolchain from any others you might have.
> > Is the hacky way the way I should be defining this cpu, or am I just
> > specifying this incorrectly? If the latter, what is the proper way to
> > specify a super specific uarch?
> >
> > Thanks,
> > squirvel
> > --
> > For unsubscribe information see http://sourceware.org/lists.html#faq

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-01-13  4:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-12 22:45 Defining a Super Specific uArch squirvel voxbox
2021-01-13  0:04 ` Chris Packham
2021-01-13  4:41   ` squirvel voxbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).