RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: ltaylorsimp...@gmail.com
> Sent: Thursday, November 16, 2023 1:19 PM
> To: Brian Cain ; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid Manning
> ; richard.hender...@linaro.org; phi...@linaro.org;
> a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> > -Original Message-
> > From: Brian Cain
> > Sent: Thursday, November 16, 2023 10:25 AM
> > To: ltaylorsimp...@gmail.com; qemu-devel@nongnu.org
> > Cc: Matheus Bernardino (QUIC) ; Sid
> > Manning ; richard.hender...@linaro.org;
> > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > oriented
> >
> >
> >
> > > -Original Message-
> > > From: ltaylorsimp...@gmail.com
> > > Sent: Wednesday, November 15, 2023 4:03 PM
> > > To: Brian Cain ; qemu-devel@nongnu.org
> > > Cc: Matheus Bernardino (QUIC) ; Sid
> > Manning
> > > ; richard.hender...@linaro.org;
> > > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > object oriented
> > >
> > > > -Original Message-
> > > > From: Brian Cain
> > > > Sent: Wednesday, November 15, 2023 1:51 PM
> > > > To: Taylor Simpson ; qemu-
> > de...@nongnu.org
> > > > Cc: Matheus Bernardino (QUIC) ; Sid
> > > > Manning ; richard.hender...@linaro.org;
> > > > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > > > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > > object oriented
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Taylor Simpson
> > > > > Sent: Thursday, November 9, 2023 3:26 PM
> > > > > To: qemu-devel@nongnu.org
> > > > > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > > > > ; Sid Manning ;
> > > > > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> > > > a...@rev.ng;
> > > > > ltaylorsimp...@gmail.com
> > > > > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > > > object oriented
> > > > >
> > > > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get
> > > > > comments on the general approach before working on the other
> > Python scripts.
> > > > >
> > > > > The generators are generally a bunch of Python if-then-else
> > > > > statements based on the regtype and regid. Encapsulate
> > > > > regtype/regid into a class hierarchy. Clients lookup the register
> > > > > and invoke methods.
> > > > >
> > > > > This has several advantages for making the code easier to read,
> > > > > understand, and maintain
> > > > > - The class name makes it more clear what the operand does
> > > > > - All the methods for a given type of operand are together
> > > > > - Don't need as many calls to hex_common.bad_register
> > > > > - We can remove the functions in hex_common that use regtype/regid
> > > > > (e.g., is_read)
> > > > >
> > > > > Signed-off-by: Taylor Simpson
> > > > > ---
> > > > > diff --git a/target/hexagon/hex_common.py
> > > > b/target/hexagon/hex_common.py
> > > > > index 0da65d6dd6..13ee55b6b2 100755
> > > > > --- a/target/hexagon/hex_common.py
> > > > > +++ b/target/hexagon/hex_common.py
> > > > > +class PredReadWrite(ReadWrite):
> > > > > +def genptr_decl(self, f, tag, regno):
> > > > > +f.write(f"const int {self.regN} =
> > > > > insn->regno[{regno}];\n")
> > > > > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > > > > +f.write(f"tcg_gen_mov_tl({self.regV},
> > hex_pred[{self.regN}]);\n")
> > > >
> > > > Instead of successive calls to f.write(), each passing their own
> > > > string with a newline, use triple quotes:
> > > >
> > > > f.write(f"""const int {self.regN} = insn->regno[{regno}];
> &
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: Brian Cain
> Sent: Thursday, November 16, 2023 10:25 AM
> To: ltaylorsimp...@gmail.com; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid
> Manning ; richard.hender...@linaro.org;
> phi...@linaro.org; a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
>
>
> > -Original Message-
> > From: ltaylorsimp...@gmail.com
> > Sent: Wednesday, November 15, 2023 4:03 PM
> > To: Brian Cain ; qemu-devel@nongnu.org
> > Cc: Matheus Bernardino (QUIC) ; Sid
> Manning
> > ; richard.hender...@linaro.org;
> > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > object oriented
> >
> > > -Original Message-
> > > From: Brian Cain
> > > Sent: Wednesday, November 15, 2023 1:51 PM
> > > To: Taylor Simpson ; qemu-
> de...@nongnu.org
> > > Cc: Matheus Bernardino (QUIC) ; Sid
> > > Manning ; richard.hender...@linaro.org;
> > > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > object oriented
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Taylor Simpson
> > > > Sent: Thursday, November 9, 2023 3:26 PM
> > > > To: qemu-devel@nongnu.org
> > > > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > > > ; Sid Manning ;
> > > > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> > > a...@rev.ng;
> > > > ltaylorsimp...@gmail.com
> > > > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > > object oriented
> > > >
> > > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get
> > > > comments on the general approach before working on the other
> Python scripts.
> > > >
> > > > The generators are generally a bunch of Python if-then-else
> > > > statements based on the regtype and regid. Encapsulate
> > > > regtype/regid into a class hierarchy. Clients lookup the register
> > > > and invoke methods.
> > > >
> > > > This has several advantages for making the code easier to read,
> > > > understand, and maintain
> > > > - The class name makes it more clear what the operand does
> > > > - All the methods for a given type of operand are together
> > > > - Don't need as many calls to hex_common.bad_register
> > > > - We can remove the functions in hex_common that use regtype/regid
> > > > (e.g., is_read)
> > > >
> > > > Signed-off-by: Taylor Simpson
> > > > ---
> > > > diff --git a/target/hexagon/hex_common.py
> > > b/target/hexagon/hex_common.py
> > > > index 0da65d6dd6..13ee55b6b2 100755
> > > > --- a/target/hexagon/hex_common.py
> > > > +++ b/target/hexagon/hex_common.py
> > > > +class PredReadWrite(ReadWrite):
> > > > +def genptr_decl(self, f, tag, regno):
> > > > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > > > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > > > +f.write(f"tcg_gen_mov_tl({self.regV},
> hex_pred[{self.regN}]);\n")
> > >
> > > Instead of successive calls to f.write(), each passing their own
> > > string with a newline, use triple quotes:
> > >
> > > f.write(f"""const int {self.regN} = insn->regno[{regno}];
> > > TCGv {self.regV} = tcg_temp_new();
> > > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n""")
> > >
> > > If necessary/appropriate, you can also use textwrap.dedent() to make
> > > the leading whitespace look appropriate:
> > > https://docs.python.org/3/library/textwrap.html#textwrap.dedent
> > >
> > > import textwrap
> > > ...
> > > f.write(textwrap.dedent(f"""const int {self.regN} = insn-
> >regno[{regno}];
> > > TCGv {self.regV} = tcg_temp_new();
> > > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n"""))
> > >
> >
> > The indenting is for the readability of the output. We could dedent
> > everything and run the result through the indent utility as
> > idef-parser does. Not sure it's worth it though.
>
> Regardless of textwrap
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: ltaylorsimp...@gmail.com
> Sent: Wednesday, November 15, 2023 4:03 PM
> To: Brian Cain ; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid Manning
> ; richard.hender...@linaro.org; phi...@linaro.org;
> a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> > -Original Message-
> > From: Brian Cain
> > Sent: Wednesday, November 15, 2023 1:51 PM
> > To: Taylor Simpson ; qemu-devel@nongnu.org
> > Cc: Matheus Bernardino (QUIC) ; Sid
> > Manning ; richard.hender...@linaro.org;
> > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > oriented
> >
> >
> >
> > > -Original Message-
> > > From: Taylor Simpson
> > > Sent: Thursday, November 9, 2023 3:26 PM
> > > To: qemu-devel@nongnu.org
> > > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > > ; Sid Manning ;
> > > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> > a...@rev.ng;
> > > ltaylorsimp...@gmail.com
> > > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > > oriented
> > >
> > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get comments
> > > on the general approach before working on the other Python scripts.
> > >
> > > The generators are generally a bunch of Python if-then-else
> > > statements based on the regtype and regid. Encapsulate regtype/regid
> > > into a class hierarchy. Clients lookup the register and invoke
> > > methods.
> > >
> > > This has several advantages for making the code easier to read,
> > > understand, and maintain
> > > - The class name makes it more clear what the operand does
> > > - All the methods for a given type of operand are together
> > > - Don't need as many calls to hex_common.bad_register
> > > - We can remove the functions in hex_common that use regtype/regid
> > > (e.g., is_read)
> > >
> > > Signed-off-by: Taylor Simpson
> > > ---
> > > diff --git a/target/hexagon/hex_common.py
> > b/target/hexagon/hex_common.py
> > > index 0da65d6dd6..13ee55b6b2 100755
> > > --- a/target/hexagon/hex_common.py
> > > +++ b/target/hexagon/hex_common.py
> > > +class ModifierSource(Source):
> > > +def genptr_decl(self, f, tag, regno):
> > > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > > +f.write(f"TCGv {self.regV} = hex_gpr[{self.regN} +
> > HEX_REG_M0];\n")
> > > +def idef_arg(self, declared):
> > > +declared.append(self.regV)
> > > +declared.append(self.regN)
> > > +
> >
> > IMO it's easier to reason about a function if it doesn't modify its inputs
> > and
> > instead it returns the transformed input. If idef_arg instead returned a
> > new
> > list or returned an iterable for the caller to catenate, it would be
> > clearer.
>
> We should figure out a better way to handle the special case of modifier
> registers. For every other register type,
> Idef_arg simply returns self.regV. For circular addressing, we also need the
> value of the corresponding CS register. Currently,
> we solve this by passing the register number so that idef-parser can get the
> value (i.e., hex_gpr[HEX_REG_CS0 + self.regN]).
>
> We could have idef-parser skip the circular addressing instructions (it
> already
> skips the bit-reverse instructions). That seems
> like a big hammer though. Any other thoughts?
>
>
> > > +class PredReadWrite(ReadWrite):
> > > +def genptr_decl(self, f, tag, regno):
> > > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > > +f.write(f"tcg_gen_mov_tl({self.regV},
> > > hex_pred[{self.regN}]);\n")
> >
> > Instead of successive calls to f.write(), each passing their own string
> > with a
> > newline, use triple quotes:
> >
> > f.write(f"""const int {self.regN} = insn->regno[{regno}];
> > TCGv {self.regV} = tcg_temp_new();
> > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n""")
> >
&g
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: Brian Cain
> Sent: Wednesday, November 15, 2023 1:51 PM
> To: Taylor Simpson ; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid
> Manning ; richard.hender...@linaro.org;
> phi...@linaro.org; a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
>
>
> > -Original Message-
> > From: Taylor Simpson
> > Sent: Thursday, November 9, 2023 3:26 PM
> > To: qemu-devel@nongnu.org
> > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > ; Sid Manning ;
> > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> a...@rev.ng;
> > ltaylorsimp...@gmail.com
> > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > oriented
> >
> > RFC - This patch handles gen_tcg_funcs.py. I'd like to get comments
> > on the general approach before working on the other Python scripts.
> >
> > The generators are generally a bunch of Python if-then-else
> > statements based on the regtype and regid. Encapsulate regtype/regid
> > into a class hierarchy. Clients lookup the register and invoke
> > methods.
> >
> > This has several advantages for making the code easier to read,
> > understand, and maintain
> > - The class name makes it more clear what the operand does
> > - All the methods for a given type of operand are together
> > - Don't need as many calls to hex_common.bad_register
> > - We can remove the functions in hex_common that use regtype/regid
> > (e.g., is_read)
> >
> > Signed-off-by: Taylor Simpson
> > ---
> > diff --git a/target/hexagon/hex_common.py
> b/target/hexagon/hex_common.py
> > index 0da65d6dd6..13ee55b6b2 100755
> > --- a/target/hexagon/hex_common.py
> > +++ b/target/hexagon/hex_common.py
> > +class ModifierSource(Source):
> > +def genptr_decl(self, f, tag, regno):
> > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > +f.write(f"TCGv {self.regV} = hex_gpr[{self.regN} +
> HEX_REG_M0];\n")
> > +def idef_arg(self, declared):
> > +declared.append(self.regV)
> > +declared.append(self.regN)
> > +
>
> IMO it's easier to reason about a function if it doesn't modify its inputs and
> instead it returns the transformed input. If idef_arg instead returned a new
> list or returned an iterable for the caller to catenate, it would be clearer.
We should figure out a better way to handle the special case of modifier
registers. For every other register type,
Idef_arg simply returns self.regV. For circular addressing, we also need the
value of the corresponding CS register. Currently,
we solve this by passing the register number so that idef-parser can get the
value (i.e., hex_gpr[HEX_REG_CS0 + self.regN]).
We could have idef-parser skip the circular addressing instructions (it already
skips the bit-reverse instructions). That seems
like a big hammer though. Any other thoughts?
> > +class PredReadWrite(ReadWrite):
> > +def genptr_decl(self, f, tag, regno):
> > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > +f.write(f"tcg_gen_mov_tl({self.regV},
> > hex_pred[{self.regN}]);\n")
>
> Instead of successive calls to f.write(), each passing their own string with a
> newline, use triple quotes:
>
> f.write(f"""const int {self.regN} = insn->regno[{regno}];
> TCGv {self.regV} = tcg_temp_new();
> tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n""")
>
> If necessary/appropriate, you can also use textwrap.dedent() to make the
> leading whitespace look appropriate:
> https://docs.python.org/3/library/textwrap.html#textwrap.dedent
>
> import textwrap
> ...
> f.write(textwrap.dedent(f"""const int {self.regN} = insn->regno[{regno}];
> TCGv {self.regV} = tcg_temp_new();
> tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n"""))
>
The indenting is for the readability of the output. We could dedent everything
and run the result through the indent utility
as idef-parser does. Not sure it's worth it though.
> > +def init_registers():
> > +registers["Rd"] = GprDest("R", "d")
> > +registers["Re"] = GprDest("R", "e")
> > +registers["Rs"] = GprSource("R", "s")
> > +registers["Rt"] = GprSource("R", "t")
> > +
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: qemu-devel-bounces+bcain=quicinc@nongnu.org AFAICT the keys for registers and new_registers can be derived from the values
> themselves. Rather than worry about copy/paste errors causing these not to
> correspond, you can create a dictionary from an iterable like so:
>
> registers = (
> GprDest("R", "d"),
> GprDest("R", "e"),
> GprSource("R", "s"),
> GprSource("R", "t"),
> ...
> )
> registers = { reg.regtype + reg.regid for reg in registers }
Sorry, forgot the value - that would yield a set and not a dict.
registers = { reg.regtype + reg.regid: reg for reg in registers }
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: Taylor Simpson
> Sent: Thursday, November 9, 2023 3:26 PM
> To: qemu-devel@nongnu.org
> Cc: Brian Cain ; Matheus Bernardino (QUIC)
> ; Sid Manning ;
> richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng; a...@rev.ng;
> ltaylorsimp...@gmail.com
> Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> RFC - This patch handles gen_tcg_funcs.py. I'd like to get comments
> on the general approach before working on the other Python scripts.
>
> The generators are generally a bunch of Python if-then-else
> statements based on the regtype and regid. Encapsulate regtype/regid
> into a class hierarchy. Clients lookup the register and invoke
> methods.
>
> This has several advantages for making the code easier to read,
> understand, and maintain
> - The class name makes it more clear what the operand does
> - All the methods for a given type of operand are together
> - Don't need as many calls to hex_common.bad_register
> - We can remove the functions in hex_common that use regtype/regid
> (e.g., is_read)
>
> Signed-off-by: Taylor Simpson
> ---
> target/hexagon/gen_tcg_funcs.py | 568 +++-
> target/hexagon/hex_common.py| 467 ++
> 2 files changed, 509 insertions(+), 526 deletions(-)
>
> diff --git a/target/hexagon/gen_tcg_funcs.py
> b/target/hexagon/gen_tcg_funcs.py
> index f5246cee6d..f7a0c59397 100755
> --- a/target/hexagon/gen_tcg_funcs.py
> +++ b/target/hexagon/gen_tcg_funcs.py
> @@ -23,454 +23,6 @@
> import hex_common
>
>
> -##
> -## Helpers for gen_tcg_func
> -##
> -def gen_decl_ea_tcg(f, tag):
> -f.write("TCGv EA G_GNUC_UNUSED = tcg_temp_new();\n")
> -
> -
> -def genptr_decl_pair_writable(f, tag, regtype, regid, regno):
> -regN = f"{regtype}{regid}N"
> -if regtype == "R":
> -f.write(f"const int {regN} = insn->regno[{regno}];\n")
> -elif regtype == "C":
> -f.write(f"const int {regN} = insn->regno[{regno}] +
> HEX_REG_SA0;\n")
> -else:
> -hex_common.bad_register(regtype, regid)
> -f.write(f"TCGv_i64 {regtype}{regid}V = " f"get_result_gpr_pair(ctx,
> {regN});\n")
> -
> -
> -def genptr_decl_writable(f, tag, regtype, regid, regno):
> -regN = f"{regtype}{regid}N"
> -if regtype == "R":
> -f.write(f"const int {regN} = insn->regno[{regno}];\n")
> -f.write(f"TCGv {regtype}{regid}V = get_result_gpr(ctx,
> {regN});\n")
> -elif regtype == "C":
> -f.write(f"const int {regN} = insn->regno[{regno}] +
> HEX_REG_SA0;\n")
> -f.write(f"TCGv {regtype}{regid}V = get_result_gpr(ctx,
> {regN});\n")
> -elif regtype == "P":
> -f.write(f"const int {regN} = insn->regno[{regno}];\n")
> -f.write(f"TCGv {regtype}{regid}V = tcg_temp_new();\n")
> -else:
> -hex_common.bad_register(regtype, regid)
> -
> -
> -def genptr_decl(f, tag, regtype, regid, regno):
> -regN = f"{regtype}{regid}N"
> -if regtype == "R":
> -if regid in {"ss", "tt"}:
> -f.write(f"TCGv_i64 {regtype}{regid}V =
> tcg_temp_new_i64();\n")
> -f.write(f"const int {regN} = insn->regno[{regno}];\n")
> -elif regid in {"dd", "ee", "xx", "yy"}:
> -genptr_decl_pair_writable(f, tag, regtype, regid, regno)
> -elif regid in {"s", "t", "u", "v"}:
> -f.write(
> -f"TCGv {regtype}{regid}V = "
> f"hex_gpr[insn->regno[{regno}]];\n"
> -)
> -elif regid in {"d", "e", "x", "y"}:
> -genptr_decl_writable(f, tag, regtype, regid, regno)
> -else:
> -hex_common.bad_register(regtype, regid)
> -elif regtype == "P":
> -if regid in {"s", "t", "u", "v"}:
> -f.write(
> -f"TCGv {regtype}{regid}V = "
> f"hex_pred[insn->regno[{regno}]];\n"
> -)
> -elif regid in {"d", "e", "x"}:
> -genptr_decl_writable(f, tag, regtype, regid, regno)
> -else:
> -hex_common.bad_register(regtype, regid)
> -elif regtype == "C":
> -if regid == "ss":
> -f.write(f"TCGv_i64 {regtype}{regid}V = "
> f"tcg_temp_new_i64();\n")
> -f.write(f"const int {regN} = insn->regno[{regno}] + "
> "HEX_REG_SA0;\n")
> -elif regid == "dd":
> -genptr_decl_pair_writable(f, tag, regtype, regid, regno)
> -elif regid == "s":
> -f.write(f"TCGv {regtype}{regid}V = tcg_temp_new();\n")
> -f.write(
> -f"const int {regtype}{regid}N = insn->regno[{regno}] + "
> -"HEX_REG_SA0;\n"
> -)
> -elif regid == "d":
> -genptr_decl_writable(f, tag, regtype, regid, regno)
> -else:
> -
Re: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
Taylor Simpson wrote: > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get comments > on the general approach before working on the other Python scripts. > > The generators are generally a bunch of Python if-then-else > statements based on the regtype and regid. Encapsulate regtype/regid > into a class hierarchy. Clients lookup the register and invoke > methods. > > This has several advantages for making the code easier to read, > understand, and maintain > - The class name makes it more clear what the operand does > - All the methods for a given type of operand are together > - Don't need as many calls to hex_common.bad_register > - We can remove the functions in hex_common that use regtype/regid > (e.g., is_read) > > Signed-off-by: Taylor Simpson Really nice! I personally think it's a great separation and it improves the code readability.
