[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 #10 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #9)
> 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"

Noooooo, this'd be mad. I meant quite the opposite: there's no need to
implement the decoder here, at all. The opcode should simply be part of
instruction data. More details below.

> 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...

The thing I'm talking about is _not_ PowerDecoder. I'm talking of basic
instruction-related information. Providing the way to quickly calculate the
opcode (both with and without the operands, but at least without them) is
natural. My point is, it's not expected to be buried that deep inside the
decoder. The opcode is expected to be part of data which is associated with the
instruction. When we parse the tables and output some stuff about the
instructions, the basic opcode (operand-less) must be part of this information.

> 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.

Subdecoders are just named tuples; the logic is buried inside TopPowerDecoder,
or, more correctly, inside its base class, PowerDecoder. Both are Elaboratable,
both do way more than obtaining the simple information (building dynamic
switches, creating some Signals and whatever stuff is under the hood). My point
is, for code generation, there's no need to rely on any of these: basically the
only stuff needed is what divide_opcodes produces. And my point is, this
information should be associated with instruction, not be hidden.

> sorry i meant to spell that out.

No, this is actually perfect that you do it, and I'm really grateful you're
doing this. First, we must discuss it; second, I'm really glad that you shed
the light to many topics, because historical background and architectural
details are priceless.

> 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.

I'm thinking of having the opcode coming as part of classes which are returned
by get_svp64_csv wrapper. That is, for each instruction, it's perfectly doable.
That is, think of it as "parse each and every CSV with the sacred knowledge of
bitsels, suffices, etc., but don't create the decoder, just calculate all the
information about the instructions that can be calculated statically,
associating the data on per-instruction basis". Basically, yes, create_pdecode
w/o the decoder, kinda like a big map of instructions (again, each instruction
is a dict-like stuff, opcode included).

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

This exactly what I'm talking of. Good to know we're on the same page.

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