[Libre-soc-bugs] [Bug 838] sync or at least statically check fields.text, power_decoder, trans/svp64, CSVs between each other

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=838

--- Comment #23 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #21)
> https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> h=785d78964c68632dbe3a09b4b5ada4c3188df078
> 
> just going through these, no sorry this is microwatt compatibility
> see (entirety of) microwatt source code esp decode.vhdl, and soc, and
> Boris Shingarov's work, and the CSV files themselves, the names
> are set in stone and cannot change now.

First, this isn't used in Microwatt or decode.vhdl or by Boris Shingarov. This
is an internal representation. It could have been anything as long as it's
clear how the conversion happens. It's like stating that "these are strings in
decode.vhdl, so you cannot treat it as integer in Python". Sorry, I'm not
buying this argument.

> i.e. i want people looking at microwatt to be able to go, "oh, these
> start OP_ and are the same name therefore must be the same"

This is more valid argument, because it's not "greppable". As I mentioned, OP_
prefix is redundant to keep in the internal representation. So it's dropped,
but still enum works it out via _missing_ method. I can make it more explicit
and introduce a mapping like {"OP_A": MicrOp.A, "OP_B": MicrOp.B}. Or even in
the enum itself, OP_A = A. I'd be surprized if it's difficult to find what
happens even now, but I can do it for explicitness.

(In reply to Luke Kenneth Casson Leighton from comment #22)
> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/
> decoder/power_insn.py;hb=9dbf16f3aa783d95ca92ad74ebef9474c7750dd2#l122
> 
> ah, sorry, just saw this - can you please try to find another way that
> does not use dataclasses.  the reason is not just that they restrict
> types but that i am endeavouring to ensure that jacob begins to respect
> python as a dynamic runtime language based around the Liskov Substitution
> Principle.  dataclasses, by being like structs of other languages,
> make a mockery of that strength of LSP.

Apparently you had the discussion about it with Jacpb, and I'm not aware of it.
When I see arguments like "it violates the LSP", I need the "why" and "how".
IRC logs or links to tasks or mailing lists are appreciated.

> a good alternative would be to turn that list of name-types into a
> dictionary and then use setattr()
> please do find another way to do that which does not use dataclass.

Rationale.

> i do not want us to have to spend the money explaining to a team
> of *HDL* engineers not used to advanced python programming what the
> hell dataclasses are.

If HDL engineers is not that advanced to type "python dataclass" in Google, I'd
say they're not engineers at all. But, anyway: there's nothing "advanced", it's
in fact a simple dict, with some sugar atop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.