[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---


On Sunday, February 16, 2020, Jean-Paul Chaput <Jean-Paul.Chaput at lip6.fr>
wrote:

  I can, I'm one of them... But not the one in charge of the mail.
  That one has just gone into vacation until the end of the month.
  I will ask him when he returns.
    Your mail is tagged as spam by spamassasin because of:

      URIBL_DBL_SPAM     Contains a spam URL listed in the Spamhaus DBL

lauri pointed me at it.  what the hell the domain's doing in that i don't know.
 it's been removed.

> having python tools that are called *by* Makefiles because make works out that
> to generate file X.ext from X.ext2, doing that job in python, is a nuisance.

  There is a tradeoff here. If your tools are separated and communicate
  through files, Makefile is the best tool.

that's what i advocate.  *make* separate tools, follow the unix philosophy,
"one thing and do it well".

    In the other hand, the paradigm of Coriolis is to integrate the
  tools so that they communicate efficiently through a common C++
  data structure, becoming a kind of a big binary blob. This is
  the acknowledged trend among this kind of tools.

for things that *require* a common c++ data structure  absoutely fantastic.

however for e.g nmigen and yosys, as external tools...


    Anyway, I try to make Coriolis "agnostic" on the way it is used,
  that is not try to enforce any specific way to use it.


> when it goes recursive, it gets even more hairy in python (bear in mind we need
> to do a hierarchical layout, not a "full automated and pray" one)
> 
> so for example, we need to generate the netlist not from a hardcoded list that
> goes into the top level Makefile, we need a *program* that generates that
> information, based on what comes out of the *nmigen* conversion to ilang.

  Sound like a more like a Python program to me than a Makefile.

eexactly.  which is called *by* the Makefile because the Makefile knows when to
call it, in order to generate the output from dependencies.

otherwise, the python program has to start doing grepping around the
filesystem, looking for partially completed dependency output, and pretty soon
you have just duplicated GNU make... in python.

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