From: Olof Johansson <olof@lixom.net>
To: Ben Dooks <ben.dooks@codethink.co.uk>
Cc: felix.chong@codethink.co.uk, lawrence.hunter@codethink.co.uk,
roan.richmond@codethink.co.uk, linux-riscv@lists.infradead.org
Subject: Re: RFC: riscv64 big endian system attempt
Date: Fri, 20 Dec 2024 11:53:47 -0800 [thread overview]
Message-ID: <Z2XLS2HX2KqBJW6U@chonkvm.lixom.net> (raw)
In-Reply-To: <20241220155801.1988785-1-ben.dooks@codethink.co.uk>
On Fri, Dec 20, 2024 at 03:57:46PM +0000, Ben Dooks wrote:
> With the latest spec adding configurable endianness, we thought we
> should try putting together a proof of concept riscv64 big endian.
>
> The full information is documented on our gitlab[1] which includes
> source repositories, build information and project documentation.
>
> We have a minimal buildroot, qemu and kernel working on QEMU.
>
> As this is a work in progress any review or help is appreciated.
While this is neat, I wonder if there's any real point in picking this
up broadly and enabling it, with the associated overhead to keep it
maintained?
While big endian ppc64 will always be close to my heart, little endian
really has taken over the world by now, even on ppc64. It used to be
that networking was the area that BE was a (soft) requirement, but with
modern CPUs having advanced faster than memory latencies and speed, doing
endian conversion in software doesn't seem to be a big deal any more.
As far as I know, ARM platforms are in the same boat -- they did some
early enablement, driven by a couple of specific use cases that didn't
significantly grow and are used in very narrow environment and with very
limited userspace.
Is this a parallel situation to that, or are there reasons to support BE
more broadly? It seems like it'd mostly split efforts and add overhead
to make sure it's still supported, even if it's a fun project to prove
that it works.
-Olof
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-12-20 19:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 15:57 RFC: riscv64 big endian system attempt Ben Dooks
2024-12-20 15:57 ` [RFC 01/15] riscv: add initial kconfig and build flags for big-endian Ben Dooks
2024-12-20 15:57 ` [RFC 02/15] add __RISCVEB__ to byteorder.h Ben Dooks
2024-12-20 15:57 ` [RFC 03/15] riscv: disable vector if big-endian, gcc unsupported option Ben Dooks
2024-12-20 15:57 ` [RFC 04/15] riscv: word-at-atime: move to generic if we're big endian Ben Dooks
2024-12-20 15:57 ` [RFC 05/15] riscv: asm: use .insn for making custom instructioons Ben Dooks
2024-12-20 15:57 ` [RFC 06/15] intiial header work Ben Dooks
2024-12-20 15:57 ` [RFC 07/15] kconfig: remove CONFIG_COMAPT for big-endian (compat cods doesn't build atm) Ben Dooks
2024-12-20 15:57 ` [RFC 08/15] defconfig: add our build config Ben Dooks
2024-12-20 15:57 ` [RFC 09/15] temp: remove various library optimisations Ben Dooks
2024-12-20 15:57 ` [RFC 10/15] riscv: fixup use of natural endian on instructions Ben Dooks
2024-12-20 15:57 ` [RFC 11/15] add todo on fpu Ben Dooks
2024-12-20 15:57 ` [RFC 12/15] riscv: bpf: big endian fixes, updated BPF_ALU ops Ben Dooks
2024-12-20 15:57 ` [RFC 13/15] riscv: probes: sort out endian-ness Ben Dooks
2024-12-20 15:58 ` [RFC 14/15] riscv: ftrace big endian updates Ben Dooks
2024-12-20 15:58 ` [RFC 15/15] riscv: traps: make insn fetch common in unknown instruction Ben Dooks
2024-12-20 19:53 ` Olof Johansson [this message]
2025-01-09 17:46 ` RFC: riscv64 big endian system attempt Palmer Dabbelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z2XLS2HX2KqBJW6U@chonkvm.lixom.net \
--to=olof@lixom.net \
--cc=ben.dooks@codethink.co.uk \
--cc=felix.chong@codethink.co.uk \
--cc=lawrence.hunter@codethink.co.uk \
--cc=linux-riscv@lists.infradead.org \
--cc=roan.richmond@codethink.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox