[Libre-soc-bugs] [Bug 845] binutils: drop svmagic and deal with the prefix instead

[bugzilla-daemon at libre-soc.org]

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

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #8)
> What really always pisses me off is that many our sources mix pure-Python
> concepts and stuff like Signal and similar crap. The pure-Python code which
> generates the C code for binutils should not really expect stuff like Signal
> or verilog or rtutil. This seriously complicates the options to use the code
> in a simple way. Why, for God's sake, if I want to generate binutils code,
> should I install verilog or nmigen!? I know, the reason is that nmigen and
> verilog needs were there way before; still we should care about it now.

because when PowerDecoder was first written 2 years ago it was
initially only intended for HDL.

i then wanted to use it in the ISACaller Simulator and thought,
"ah HA! if i pass in an abstract class instance which has the exact
same capability as nmigen Signal, nmigen Switch, nmigen Case and nmigen
Mux, i can make a PowerDecoder which does NOT depend on nmigen"

it should be fairly obvious from the fact that this has not *yet*
happened that it was decided that (a) there wasn't time and (b) PowerDecoder
is already so horrendously abstract that it would cause people to run
away screaming...

> But, putting this rage aside for a while (I'm not yet done with it, we'll
> return to this question eventually, because this is fundamentally wrong):
> divide_opcodes has most of what we need. I'll think of how to handle this.
> Either I'll create a PowerDecoder (duplicating some of create_pdecode stuff)
> or will handle it in a bit different way.

no please REALLY do not duplicate the functionality of PowerDecoder,
it is extremely sophisticated and it would be a nightmare to
have two sets of code.  that's my first instinctive reaction.

the second reaction is: actually it may only be about 250 lines
so you might get away with it, but it is really complex data structures
so making me nervous.

my third reaction is, you've completely missed the point (aside from
the import, which could be solved by splitting out the appropriate
code) and it is this: you don't *actually* need to call any nmigen
at all, you only need to walk the data structures (the static hierarchy
of Named Tuples) to get the XOs.

in other words what you are seeing as a dependency on nmigen is ONLY
caused by these lines:

 767     return TopPowerDecoder(32, dec, name=name, col_subset=col_subset,
 768                            row_subset=row_subset,
 769                            conditions=conditions)
 770 

if you move the entire contents of create_pdecode except that one line
into a submodule and move Subdecoder (line 110) to the same file i think
you'll find the problem (for you) has completely gone away.

sorry i meant to spell that out.

yes v. likely that divide_opcodes() creates the mask needed for spotting
XO patterns, feel free to create a class that duplicates the recursive
walk of PowerDecoder but only after moving the majority of create_pdecode
and Subdecoder to a separate module, calling that new function from
power_decoder.py:create_pdecode(), and making damn sure everything still
works, first.

the last thing we need is two duplicate places of supported opcodes.

bottom line is, the information you are after is actually obtainable
and does not need nmigen, at all.

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