| Summary: | change HDL code to not use type annotations even for dataclasses | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Jacob Lifshay <programmerjake> |
| Component: | Source Code | Assignee: | Jacob Lifshay <programmerjake> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | libre-soc-bugs, lkcl, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| NLnet milestone: | NLnet.2021.02A.052.CryptoRouter | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | 771 |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: |
jacob=0
|
|
|
Description
Jacob Lifshay
2022-08-10 08:59:57 BST
started adding the @plain_data() decorator and tests: https://git.libre-soc.org/?p=nmutil.git;a=commit;h=80d0f36d1fa88f28f6f8709a5f19043ef602272b Finished implementing plain_data.
It's nicer to use than dataclass if you have a frozen instance and you write your own __init__, because it still allows field writes until __init__ finishes running:
@dataclass(frozen=True)
class MyData:
a: int
b: int
def __init__(self, a, b):
# insert custom logic here
# we have to use object.__setattr__ to bypass the frozen-type logic
object.__setattr__(self, "a", a)
object.__setattr__(self, "b", b)
@plain_data(frozen=True)
class MyData:
__slots__ = "a", "b"
def __init__(self, a, b):
# insert custom logic here
self.a = a
self.b = b
Converted prefix_sum.py to use plain_data instead of dataclass:
https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/prefix_sum.py;h=65f2b33eaf079889590d5aa13ffb6fdb28f1628c;hb=fcbd2f816210cd48879f05ac6d342f93409e03b4#l13
I finished replacing dataclass in most the rest of the code (nmutil, nmigen-gf, and ieee754fpu), only place left is goldschmidt_div_sqrt. I'm not replacing dataclass in nmigen, sby, or sv_binutils.py. that covers everything I have checked out on my computer. (In reply to Jacob Lifshay from comment #3) > I finished replacing dataclass in most the rest of the code (nmutil, > nmigen-gf, and ieee754fpu), only place left is goldschmidt_div_sqrt. > > I'm not replacing dataclass in nmigen, sby, hell no, they're "outside the HDL remit" and i explained that the strictness of dataclasses is strongly appropriate for formal correctness. > or sv_binutils.py. that's down to dmitry, the case for using dataclass there is... [annoyingly-but-i-got-over-it] justifiable. now that plain_data exists it *might* be useable... > that covers everything I have checked out on my computer. fantastic, thank you jacob. I added nmutil.plain_data.fields and nmutil.plain_data.replace utility functions, based on the dataclasses.fields and dataclasses.replace functions. I finished converting all dataclasses usages in the HDL. idk if this is the right parent task, lkcl, please fill out the payment details as appropriate. (In reply to Jacob Lifshay from comment #5) > I added nmutil.plain_data.fields and nmutil.plain_data.replace utility > functions, based on the dataclasses.fields and dataclasses.replace functions. > > I finished converting all dataclasses usages in the HDL. brilliant. it maaay actually be appropriate to consider moving them to nmigen, as one of the candidates for moving to nmigen is RecordObject, augmenting it to use this. (In reply to Jacob Lifshay from comment #6) > idk if this is the right parent task, lkcl, please fill out the payment > details as appropriate. 771? no - there's another place it can go, under the Horizon2020 grants. |