From: Michael Ellerman <mpe@ellerman•id.au>
To: Nicholas Piggin <npiggin@gmail•com>, Jordan Niethe <jniethe5@gmail•com>
Cc: Alistair Popple <alistair@popple•id.au>,
Daniel Axtens <dja@axtens•net>,
linuxppc-dev@lists•ozlabs.org,
Balamuruhan S <bala24@linux•ibm.com>
Subject: Re: [PATCH v4 03/16] powerpc: Use a datatype for instructions
Date: Tue, 24 Mar 2020 13:58:51 +1100 [thread overview]
Message-ID: <87369yzces.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <1584956855.oidzv2r2fr.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail•com> writes:
> Jordan Niethe's on March 23, 2020 7:28 pm:
>> On Mon, Mar 23, 2020 at 5:27 PM Nicholas Piggin <npiggin@gmail•com> wrote:
>>> Jordan Niethe's on March 20, 2020 3:17 pm:
>>> > Currently unsigned ints are used to represent instructions on powerpc.
>>> > This has worked well as instructions have always been 4 byte words.
>>> > However, a future ISA version will introduce some changes to
>>> > instructions that mean this scheme will no longer work as well. This
>>> > change is Prefixed Instructions. A prefixed instruction is made up of a
>>> > word prefix followed by a word suffix to make an 8 byte double word
>>> > instruction. No matter the endianess of the system the prefix always
>>> > comes first. Prefixed instructions are only planned for powerpc64.
>>> >
>>> > Introduce a ppc_inst type to represent both prefixed and word
>>> > instructions on powerpc64 while keeping it possible to exclusively have
>>> > word instructions on powerpc32, A latter patch will expand the type to
>>> > include prefixed instructions but for now just typedef it to a u32.
>>> >
>>> > Later patches will introduce helper functions and macros for
>>> > manipulating the instructions so that powerpc64 and powerpc32 might
>>> > maintain separate type definitions.
>>>
>>> ppc_inst_t I would slightly prefer for a typedef like this.
>> Are _t types meant to be reserved?
>
> No, just convention that structs are not normally typedefed unless
> they are a pervasive interface that gets passed around a lot but
> does not get accessed without accessor functions much. When you do
> typedef them, add a _t (or less frequently _s/_u/etc). pte_t,
> cpumask_t, atomic_t.
Ideally we wouldn't use a typedef, we'd just have:
struct ppc_inst {
u32 val;
#ifdef CONFIG_PPC64
u32 suffix;
#endif
};
That may make the conversion harder though, because you more or less
have to update all usages at once.
cheers
next prev parent reply other threads:[~2020-03-24 3:02 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 5:17 [PATCH v4 00/16] Initial Prefixed Instruction support Jordan Niethe
2020-03-20 5:17 ` [PATCH v4 01/16] powerpc/xmon: Remove store_inst() for patch_instruction() Jordan Niethe
2020-03-23 6:19 ` Nicholas Piggin
2020-03-20 5:17 ` [PATCH v4 02/16] xmon: Move out-of-line instructions to text section Jordan Niethe
2020-03-23 5:59 ` Balamuruhan S
2020-03-23 6:05 ` Balamuruhan S
2020-03-23 9:26 ` Jordan Niethe
2020-03-23 6:22 ` Nicholas Piggin
2020-03-20 5:17 ` [PATCH v4 03/16] powerpc: Use a datatype for instructions Jordan Niethe
2020-03-23 6:07 ` Balamuruhan S
2020-03-23 6:23 ` Nicholas Piggin
2020-03-23 9:28 ` Jordan Niethe
2020-03-23 9:51 ` Nicholas Piggin
2020-03-24 2:58 ` Michael Ellerman [this message]
2020-03-24 3:21 ` Jordan Niethe
2020-04-01 10:32 ` Balamuruhan S
2020-04-01 23:52 ` Jordan Niethe
2020-04-02 23:44 ` Alistair Popple
2020-04-03 0:09 ` Jordan Niethe
2020-03-20 5:17 ` [PATCH v4 04/16] powerpc: Use a macro for creating instructions from u32s Jordan Niethe
2020-03-23 6:26 ` Nicholas Piggin
2020-03-23 9:29 ` Jordan Niethe
2020-03-20 5:17 ` [PATCH v4 05/16] powerpc: Use a function for masking instructions Jordan Niethe
2020-03-23 6:37 ` Nicholas Piggin
2020-03-23 9:31 ` Jordan Niethe
2020-03-20 5:17 ` [PATCH v4 06/16] powerpc: Use a function for getting the instruction op code Jordan Niethe
2020-03-23 6:54 ` Balamuruhan S
2020-03-23 9:35 ` Jordan Niethe
2020-03-20 5:18 ` [PATCH v4 07/16] powerpc: Introduce functions for instruction nullity and equality Jordan Niethe
2020-03-23 6:43 ` Nicholas Piggin
2020-03-23 9:31 ` Jordan Niethe
2020-03-20 5:18 ` [PATCH v4 08/16] powerpc: Use an accessor for word instructions Jordan Niethe
2020-03-23 11:12 ` Balamuruhan S
2020-03-24 3:18 ` Jordan Niethe
2020-03-24 6:22 ` Balamuruhan S
2020-03-20 5:18 ` [PATCH v4 09/16] powerpc: Use a function for reading instructions Jordan Niethe
2020-03-23 8:00 ` Nicholas Piggin
2020-03-23 8:43 ` Balamuruhan S
2020-03-23 10:09 ` Jordan Niethe
2020-03-23 10:36 ` Nicholas Piggin
2020-03-20 5:18 ` [PATCH v4 10/16] powerpc: Make test_translate_branch() independent of instruction length Jordan Niethe
2020-03-20 5:18 ` [PATCH v4 11/16] powerpc: Enable Prefixed Instructions Jordan Niethe
2020-03-23 7:02 ` Nicholas Piggin
2020-03-20 5:18 ` [PATCH v4 12/16] powerpc: Define new SRR1 bits for a future ISA version Jordan Niethe
2020-03-23 7:03 ` Nicholas Piggin
2020-03-20 5:18 ` [PATCH v4 13/16] powerpc: Support prefixed instructions in alignment handler Jordan Niethe
2020-03-23 7:05 ` Nicholas Piggin
2020-03-23 9:35 ` Jordan Niethe
2020-03-20 5:18 ` [PATCH v4 14/16] powerpc64: Add prefixed instructions to instruction data type Jordan Niethe
2020-03-23 6:58 ` Nicholas Piggin
2020-03-23 7:33 ` Nicholas Piggin
2020-03-23 23:45 ` Jordan Niethe
2020-03-24 5:40 ` Nicholas Piggin
2020-03-30 9:05 ` Alistair Popple
2020-03-30 9:13 ` Jordan Niethe
2020-03-20 5:18 ` [PATCH v4 15/16] powerpc sstep: Add support for prefixed load/stores Jordan Niethe
2020-03-23 8:54 ` Balamuruhan S
2020-03-20 5:18 ` [PATCH v4 16/16] powerpc sstep: Add support for prefixed fixed-point arithmetic Jordan Niethe
2020-03-23 10:05 ` Balamuruhan S
2020-03-23 6:18 ` [PATCH v4 00/16] Initial Prefixed Instruction support Nicholas Piggin
2020-03-23 9:25 ` Jordan Niethe
2020-03-23 10:17 ` Nicholas Piggin
2020-03-24 2:54 ` Jordan Niethe
2020-03-24 2:59 ` Jordan Niethe
2020-03-24 5:44 ` Nicholas Piggin
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=87369yzces.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=alistair@popple$(echo .)id.au \
--cc=bala24@linux$(echo .)ibm.com \
--cc=dja@axtens$(echo .)net \
--cc=jniethe5@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=npiggin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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