[libre-riscv-dev] div/mod algorithm written in python

Jacob Lifshay programmerjake at gmail.com
Fri Jul 5 11:14:36 BST 2019

On Fri, Jul 5, 2019 at 3:01 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> ________________________________
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> On Fri, Jul 5, 2019 at 10:51 AM Jacob Lifshay programmerjake at gmail.com wrote:
> >
> On Fri, Jul 5, 2019 at 2:46 AM Luke Kenneth Casson Leighton
> lkcl at lkcl.net wrote:
> >
> On Friday, July 5, 2019, Jacob Lifshay programmerjake at gmail.com wrote:
> >
> I'm not sure how setup and
> process are supposed to be defined,
> there's lots or examples and they're documented in nmutil/iocontrol.py
> setup can be ignored entirely for non-module-based combinatorial stages.
> done. this should work:
Your patch appears to have been Obliterated by GMail (TM)

> with module-based designs, setup takes the module that submodules must be
> added to,
> Seems like a bad design,
> it's topologically directly equivalent to the code that you advocated,
> passing in "m" (the module) in order to access m.d.comb.
> since the calling code should be able to pick
> the submodule names, not the called code. What happens if a module
> needs to make 2 instances of the same class as different submodules?
> design the pipeline so that it doesn't, is the simplest answer, there.
> the parent modules are themselves added into other modules. the chances
> of a clash are minimal.
Well, I wanted to use module-based classes to implement the div pipeline:
stages = [DivPipeCoreSetupStage(core_config)]
for stage_index in range(core_config.num_calcluate_stages):
    stages.append(DivPipeCoreCalculateStage(core_config, stage_index))
chain = StageChain(stages)

now, there isn't any name I can use for the submodule in
DivPipeCoreCalculateStage.setup(), since the next instance will
interfere with it.


More information about the libre-riscv-dev mailing list