All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Niethe <jniethe5@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
Date: Fri, 3 Jun 2022 15:03:05 +1000	[thread overview]
Message-ID: <CACzsE9o8wQj+cCqQmWefKttqHtJ2PpmDULbaiCH=DK3Cj6i1ow@mail.gmail.com> (raw)
In-Reply-To: <20220602084654.GZ25951@gate.crashing.org>

On Thu, Jun 2, 2022 at 6:49 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Thu, Jun 02, 2022 at 01:01:04PM +1000, Jordan Niethe wrote:
> > > What about the more fundamental thing?  Have the order of the two halves
> > > of a prefixed insn as ulong not depend on endianness?  It really is two
> > > opcodes, and the prefixed one is first, always, even in LE.
> > The reason would be the value of as ulong is then used to write a
> > prefixed instruction to
> > memory with std.
> > If both endiannesses had the halves the same one of them would store
> > the suffix in front of the prefix.
>
> You cannot do such a (possibly) unaligned access from C though, not
> without invoking undefined behaviour.  The compiler usually lets you get
> away with it, but there are no guarantees.  You can make sure you only
> ever do such an access from assembler code of course.

Would using inline assembly to do it be ok?

>
> Swapping the two halves of a register costs at most one insn.  It is
> harmful premature optimisation to make this single cycle advantage
> override more important consideration (almost everything else :-) )

I'm not sure I follow. We are not doing this as an optimisation, but
out of the necessity of writing
the prefixed instruction to memory in a single instruction so that we
don't end up with half an
instruction in the kernel image.

>
>
> Segher

  reply	other threads:[~2022-06-03  5:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31  6:59 [PATCH] powerpc/64: Drop ppc_inst_as_str() Michael Ellerman
2022-05-31 22:27 ` Segher Boessenkool
2022-06-01 10:43   ` Michael Ellerman
2022-06-01 16:20     ` Segher Boessenkool
2022-06-02  3:01       ` Jordan Niethe
2022-06-02  8:46         ` Segher Boessenkool
2022-06-03  5:03           ` Jordan Niethe [this message]
2022-06-03 12:49             ` Segher Boessenkool
2022-06-01  3:03 ` Bagas Sanjaya
2022-06-01  3:30   ` Bagas Sanjaya
2022-07-04 11:33 ` Michael Ellerman

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='CACzsE9o8wQj+cCqQmWefKttqHtJ2PpmDULbaiCH=DK3Cj6i1ow@mail.gmail.com' \
    --to=jniethe5@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=segher@kernel.crashing.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.