[libre-riscv-dev] extremely busy crowdsupply update started

[libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/023_2020mar26_decoder_emulator_started.mdwn;hb=HEAD

this is just the beginning, i have to fill in the sections - it would
be really handy if people could help!

* jacob in particular on the algorithmic library
* jock on how you got on with the coriolis2 thing (even if it's "it
was total chaos")
* yehowshua if you could write a paragraph or two about CREATE-X
* michael could you do something about the use of GNU as and qemu?

if you prefer just reply to this message with a paragraph or two and i
will cut/paste it?  i'll do the conf-call and the Talos-II
workstation.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jacob Lifshay]

On Thu, Mar 26, 2020 at 2:04 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/023_2020mar26_decoder_emulator_started.mdwn;hb=HEAD
>
> this is just the beginning, i have to fill in the sections - it would
> be really handy if people could help!
>
> <snip>
>
> if you prefer just reply to this message with a paragraph or two and i
> will cut/paste it?  i'll do the conf-call and the Talos-II
> workstation.

I ended up with quite a bit more than a paragraph or two, hoping
that's ok since this is the first time simple-soft-float as appeared
in the CrowdSupply updates, and I've been working on it since june at
least. I'd appreciate a review by someone else to help catch errors. I
pushed my additions to crowdsupply.git.

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Friday, March 27, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

>
> I ended up with quite a bit more than a paragraph or two, hoping
> that's ok since this is the first time simple-soft-float as appeared
> in the CrowdSupply updates, and I've been working on it since june at
> least. I'd appreciate a review by someone else to help catch errors. I
> pushed my additions to crowdsupply.git.


looks great jacob.

were there any challenges or anything that was difficult or easy?  it is
"insights" that are the kind of thing that make updates interesting.

oh, do mention the "rust library of the month" thing for example, and when
that happened, and how what has been done expands on that since.

also i suggest explicitly mentioning that these two libraries can be used
by *anyone*, they are *not* specific to this project, and are exactly the
kind of side-benefit that comes from sponsorship from NLNet.  hm i might
word that one if that's ok.


oh, nearly forgot! can you also do a quick section on kazan, mentioning the
intermediary milestone?


cole do you want to write a paragraph or two about the build servers?  link
to the post you did a few days ago


veera, the public-inbox setup (and how it helps other people not just us?)

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jacob Lifshay]

On Fri, Mar 27, 2020, 01:47 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Friday, March 27, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> >
> > I ended up with quite a bit more than a paragraph or two, hoping
> > that's ok since this is the first time simple-soft-float as appeared
> > in the CrowdSupply updates, and I've been working on it since june at
> > least. I'd appreciate a review by someone else to help catch errors. I
> > pushed my additions to crowdsupply.git.
>
>
> looks great jacob.
>
> were there any challenges or anything that was difficult or easy?  it is
> "insights" that are the kind of thing that make updates interesting.
>
> oh, do mention the "rust library of the month" thing for example, and when
> that happened, and how what has been done expands on that since.
>
> also i suggest explicitly mentioning that these two libraries can be used
> by *anyone*, they are *not* specific to this project, and are exactly the
> kind of side-benefit that comes from sponsorship from NLNet.  hm i might
> word that one if that's ok.
>
>
> oh, nearly forgot! can you also do a quick section on kazan, mentioning the
> intermediary milestone?
>

Will add all the above stuff later, may have to delay till saturday night
or sunday.

Jacob

>
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 9:31 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> Will add all the above stuff later, may have to delay till saturday night
> or sunday.

ok great.  no problem.

btw we need to start getting smart, work together, and get the
hardware (and simulator) operational with basic POWER integer
functionality, then LDs/STs (even if there's no efficient memory
read/write), then probably branches (with simple branch-prediction,
first).

i'm finding that i'm working well *with* people (poking in here and
there) such as you and michael (and Mitch, last year), however if i'm
doing something on my own - from scratch - i'm ridiculously slow.  two
weeks so far on the LD/ST buffer.  the IEEE754 work was an exception
because i had "something that worked" (the jondawson fpu) and could
rapidly morph it.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jacob Lifshay]

On Fri, Mar 27, 2020 at 1:47 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Friday, March 27, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> >
> > I ended up with quite a bit more than a paragraph or two, hoping
> > that's ok since this is the first time simple-soft-float as appeared
> > in the CrowdSupply updates, and I've been working on it since june at
> > least. I'd appreciate a review by someone else to help catch errors. I
> > pushed my additions to crowdsupply.git.
>
>
> looks great jacob.
>
> were there any challenges or anything that was difficult or easy?  it is
> "insights" that are the kind of thing that make updates interesting.

Added a little on that in the Kazan shader compiler section.

> oh, do mention the "rust library of the month" thing for example, and when
> that happened, and how what has been done expands on that since.

Added the mention, algebraics was the Crate of the Week back in October.
>
> also i suggest explicitly mentioning that these two libraries can be used
> by *anyone*, they are *not* specific to this project, and are exactly the
> kind of side-benefit that comes from sponsorship from NLNet.  hm i might
> word that one if that's ok.

Seems as though you added that.
>
>
> oh, nearly forgot! can you also do a quick section on kazan, mentioning the
> intermediary milestone?

I ended up writing a whole new big section on the shader compiler IR.
We should probably copy a lot of that to our documentation.

At this point, we should probably split the update into multiple
separate updates or something, it's getting too long to easily read.

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Immanuel, Yehowshua U]

> * yehowshua if you could write a paragraph or two about CREATE-X

Yes, let me get back to you later today.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 2:39 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> > * yehowshua if you could write a paragraph or two about CREATE-X
>
> Yes, let me get back to you later today.

thanks.  you are actually on the list for this repo so could git
commit if you wanted to
https://git.libre-riscv.org/?p=crowdsupply.git;a=summary

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Tobias Platen]

On Fri, 27 Mar 2020 15:49:45 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

I've cloned the repository and now I could write something to fill one or more TODOs in the file 023_2020mar26_decoder_emulator_started.mdwn probably either Coriolis2 experimentation started or POWER ISA decoder and Simulator. I think I'll work on the POWER ISA decoder and Simulator next. 

> On Fri, Mar 27, 2020 at 2:39 PM Immanuel, Yehowshua U
> <yimmanuel3@gatech.edu> wrote:
> >
> > > * yehowshua if you could write a paragraph or two about CREATE-X
> >
> > Yes, let me get back to you later today.
> 
> thanks.  you are actually on the list for this repo so could git
> commit if you wanted to
> https://git.libre-riscv.org/?p=crowdsupply.git;a=summary
> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev


-- 
Tobias Platen <libre-soc[at]platen-software[dot]de>

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 4:35 PM Tobias Platen
<libre-soc@platen-software.de> wrote:
>
> On Fri, 27 Mar 2020 15:49:45 +0000
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> I've cloned the repository and now I could write something to fill one or more TODOs in the file 023_2020mar26_decoder_emulator_started.mdwn probably either Coriolis2 experimentation started or POWER ISA decoder and Simulator.

sure - i've added you to the repo so you can git push to it.

> I think I'll work on the POWER ISA decoder and Simulator next.

i had an idea about that, based on this:

http://lists.mailinglist.openpowerfoundation.org/pipermail/openpower-hdl-cores/2020-March/000007.html

my feeling is, we're wasting our time trying to "manually" create both
a processor and also a simulator, from "scratch", when there are
perfectly good, machine-readable expressions (at least for the integer
instructions), like this:

lbz         RT,D(RA)
    34      RT      RA     D
0        6       11     16   31
if RA = 0 then b <= 0
else           b <= (RA)
EA <= + EXTS(D)
RT <= 56^0 || MEM(EA, 1)

i'm advocating, therefore, that we *literally* parse the PDF spec,
create an "interpreter" for those fragments, then auto-generate code
and HDL from them.

mulhwu      RT,RA,RB                      (Rc=0)
mulhwu.     RT,RA,RB                      (Rc=1)
    31      RT      RA      RB    /    11    Rc
0        6       11      16      21 22       31

prod0:63 <- (RA)32:63 x (RB)32:63
RT32:63 <- prod0:31
RT0:31 <- undefined

those really don't look very hard, to turn into code, do they?

FP is a little more challenging because they use "words" to describe
most aspects of the hardware.  oh wait!  Appendix A p775 v3.0B
contains FP to rounding algorithms, and a few more besides.

i would not be at all surprised if, should we do document-parsing, we
had an entire simulator for the integer V3.0 system in a week, and the
hardware in around 2.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jacob Lifshay]

On Fri, Mar 27, 2020, 12:21 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> FP is a little more challenging because they use "words" to describe
> most aspects of the hardware.  oh wait!  Appendix A p775 v3.0B
> contains FP to rounding algorithms, and a few more besides.
>
> i would not be at all surprised if, should we do document-parsing, we
> had an entire simulator for the integer V3.0 system in a week, and the
> hardware in around 2.


I haven't looked at the specific FP algorithms the Power spec specifies
yet, but assuming they are like how IEEE 754 is specified, they specify it
in terms of infinite-precision real numbers, which are not mappable to
hardware without additional conversion to integer/fixed-point operations.

Jacob

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 9:29 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> I haven't looked at the specific FP algorithms the Power spec specifies
> yet, but assuming they are like how IEEE 754 is specified, they specify it
> in terms of infinite-precision real numbers, which are not mappable to
> hardware without additional conversion to integer/fixed-point operations.

it appears to be bit-numbered sections of the incoming data.  like this:

If (FRB)1:11 < 897 and (FRB)1:63 > 0 then
     Do
         If FPSCRUE = 0 then goto Disabled Exponent Underflow
         If FPSCRUE = 1 then goto Enabled Exponent Underflow
     End

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Mar 27, 2020 at 7:20 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

> my feeling is, we're wasting our time trying to "manually" create both
> a processor and also a simulator, from "scratch", when there are
> perfectly good, machine-readable expressions (at least for the integer
> instructions), like this:

captured here:
http://bugs.libre-riscv.org/show_bug.cgi?id=269

let's discuss that on that bugreport.

btw, one important thing: the "original" NLNet Grant is *running low*
because of our need to transfer to POWER ISA (the expectation was to
use an existing RV codebase such as minerva and jump-start straight
from running working code).

therefore, the way we need to do this is for people to pitch in with
other tasks that *are* allocated new budgets, such as the Simulator,
formal proofs, and so on.

this means we need to *up our game* somewhat because we'll need to
work collaboratively and keep in touch regularly.  suggestions on how
to do that appreciated.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Michael Nolan]

On 3/26/20 5:03 PM, Luke Kenneth Casson Leighton wrote:
> https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/023_2020mar26_decoder_emulator_started.mdwn;hb=HEAD
>
> this is just the beginning, i have to fill in the sections - it would
> be really handy if people could help!
>
> * michael could you do something about the use of GNU as and qemu?
Sure, I'll work on it at some point today or tomorrow.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Fri, Mar 27, 2020 at 4:56 PM Michael Nolan <mtnolan2640@gmail.com> wrote:

> > * michael could you do something about the use of GNU as and qemu?
> Sure, I'll work on it at some point today or tomorrow.

star.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jock Tanner]

Hi!

On Thu, 2020-03-26 at 21:03 +0000, Luke Kenneth Casson Leighton wrote:
> * jock on how you got on with the coriolis2 thing (even if it's "it
> was total chaos")

> if you prefer just reply to this message with a paragraph or two and
> i

I also can not put my first impressions in just one or two paragraphs,
so I wrote two versions. Luke, please choose the most appropriate one.

Short version (TL/DR)
=====================

As a humble Python developer, I understand the unique status and
significance of the Coriolis project, nevertheless I cannot help but
notice that it has a huge room for improvement. I genuinely hope that
my participation in libre-riscv will also help improve Coriolis.

Detailed version (The Rant)
===========================

1. Installation

Coriolis 2 can be built and installed two ways:

  a) inside the home directory (“Fixed directory tree”), using a helper
script [1],
  b) as a package, either RPM or DEB [2].

I followed the (a) route, and it actually went well except for a couple
of quirks, that is considering the number of dependencies. As I
understand, the (b) way is not well maintained for now.

The method (a) can be used per se, at least on Debian GNU/Linux, or
within chroot or LXC environments.

Unfortunately, the Python extensions are coupled with the rest of the
Coriolis, so it is impossible to use the advantages of 'virtualenv' or
similar environments with Coriolis.

Thus, entering the development with Coriolis for pythonistas is
complicated by the combination of two factors:

- lack of native packages for their OSes,
- lack of PyPI package or pip/virtualenv support.

I understand that Coriolis is a niche product, so we can not really
expect much in terms of packaging for popular OSes. So it may be better
for Coriolis to take another route:

- decouple Python extensions from the main product,
- provide Python extensions as a pip package (via PyPI or git),
- supply a script and/or instructions for building the main product
with the pip package.

This is actually not a unique approach. For example, xapian-haystack
ships a script for building a whole Xapian search engine (C++) in
PYTHONPATH [3].

2. Documentation
.
All the basics are covered by Coriolis User's Guide [4] (general
workflow and GUI) and Python Tutorial [5], that are available online
and offline, in PDF and HTML formats.

Unfortunately, Coriolis Python API don't have its own reference guide.
There is a good reference on Hurricane C++ API [6] though. Since Python
API just copies the C++ API (which is a terrible desicion by itself,
see the explanation in 3.2), this reference alone has the great part of
both C++ and Python APIs covered. But other parts of the Python API
(most importantly, Etesian and Katana) stays undocumented beyond the
basics.

3. API

3.1. Supported Python versions

The Coriolis Python API is a Python 2 extension.

Python 2.7 was released in 2010, and it was meant to be the last 2.x
release back then. In the following years Python 2 had no new features
other than backports from Python 3. As of January 2020 Python 2 is
considered unsupported by PSF. [7]

Still clinging to outdated and abandoned language and not even having a
(publicly available, at least) transition plan seems a bit scary to me.

3.2. Best practices of Python APIs

To have a new API mimic the old API written in another programming
language seems like an excellent idea at first. You don't have to
design anything. Don't have to think of naming. You can reuse
documentation and tests. The new API is easy to use, if you already got
used to the old one. Everybody's happy, right?

Well, everybody except the end users whom the new API is created for.

Each programming language has its own best practices, and most of the
time they either contradict the ones accepted by another language users
or just don't have analogues in that language. Your new users will see
your API as alien, cumbersome, or just poorly designed. They may have
to cram their way around the least expected features. They may have to
write wrappers around your API to reduce the astonishment factor [8]
for the others. But most likely they will simply walk away.

Here I'll try to give a run-down of Coriolis API features that scares
Python developers (“bad”) along with their attractive and comfy
alternatives (“good”).

3.2.1. Singletons

You don't need a special methods to create and access a unique object
in Python, since you can just import it.

Bad: af = CRL.AllianceFramework.get()

Good: from CRL import af

3.2.2. Getters and setters

Getters and setters are considered an antipattern (not only in Python),
so they should be replaced by properties or collection-like interfaces.

Bad:
  env = af.getEnvironment()
  env.setCLOCK('^ck$|m_clock|^clk$')

Good:
  af.env['CLOCK'] = '^ck$|m_clock|^clk$'

3.2.3. Data types

Python use duck typing, so you should avoid any direct type indication
or querying in Python.

Bad: Cfg.getParamInt('katana.vTracksReservedLocal').setInt(6)

Good: Cfg['katana.vTracksReservedLocal'] = 6

3.2.4. Syntactic sugar

It's easier to account for the certain things that goes in pairs
(open/close, create/destroy) with context managers or decorators.

Bad:
  UpdateSession.open()
  do_my_thing()
  UpdateSession.close()

Good:
  with UpdateSession():
      do_my_thing()

Also good in some cases:
  @update_session
  def do_my_thing():
      ...

3.2.5. Self-documenting

Python have a built-in 'help()' function, that returns a docstring for
a given object. Python C extensions can emulate a docstring for use
with 'help()'. Static syntax checkers and IDEs also rely on this API.

It is very important that this emulated docstring contains not only the
description of the function or method, but also a signature (parameters
and return value) in reST format, as recommended by PEP287 [9], or in
older Epytext format at worst. This will greatly facilitate the use of
Python C extension with modern IDEs.

The rules have slightly changed since Python 3.4, but the idea remains.

3.2.6. Naming conventions

The Python API must adhere to naming conventions accepted in Python. I
can not stress enough the importance of this point, but let us address
the styling issues in general in 3.3.

3.3. Styling

I have to admit that Coriolis Python style is quite consistent, but it
looks like the only purpose of this consistency is to contradict the
PEP 8 [10] in any possible way. [11]

You might think that style is not that important, but after 15 minutes
spent in search of the 'ChipRoute' class definition, diagnosing and
restarting IDE, checking Moon phase and whatnot, find that 'ChipRoute' 
is not a class, but a module… How well the end user could perform with
that in mind?

Another thing is that it's nearly impossible to lure a junior developer
into a project that neglects styling. In modern development,
proprietary and opensource alike, an ability to write a consistent,
readable, uniform code is very much appreciated, and junior developers
expect to acquire good professional habits in their first projects. And
style is the first thing they learn to distinguish in someone else's
code.

[1] http://coriolis.lip6.fr/pages/users-guide.html#id16
[2] http://coriolis.lip6.fr/pages/users-guide.html#id19
[3] https://github.com/notanumber/xapian-haystack
[4] http://coriolis.lip6.fr/pages/users-guide.html
[5] http://coriolis.lip6.fr/pages/python-tutorial.html
[6] http://coriolis.lip6.fr/doc/hurricane/index.html
[7] https://www.python.org/dev/peps/pep-0373/
[8] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
[9] https://www.python.org/dev/peps/pep-0287/
[10] https://www.python.org/dev/peps/pep-0008/
[11] 
https://www.opensourceshakespeare.org/views/plays/play_view.php?WorkID=hamlet&Act=2&Scene=2&Scope=scene&LineHighlight=1307#1307



_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Saturday, March 28, 2020, Jock Tanner <tanner.of.kha@gmail.com> wrote:

> Hi!
>
> On Thu, 2020-03-26 at 21:03 +0000, Luke Kenneth Casson Leighton wrote:
> > * jock on how you got on with the coriolis2 thing (even if it's "it
> > was total chaos")
>
> > if you prefer just reply to this message with a paragraph or two and
> > i
>
> I also can not put my first impressions in just one or two paragraphs,
> so I wrote two versions. Luke, please choose the most appropriate one.


short for thecrowdsupply update, with a link here for the people interested
to read.  also i will specially include the insights about putting people
off due to the nonstandard style., that's quite important.

nicely done jock.



>
> Short version (TL/DR)
> =====================
>
> As a humble Python developer, I understand the unique status and
> significance of the Coriolis project, nevertheless I cannot help but
> notice that it has a huge room for improvement. I genuinely hope that
> my participation in libre-riscv will also help improve Coriolis.
>
>

-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jean-Paul Chaput]

[-- Attachment #1.1: Type: text/plain, Size: 15793 bytes --]


Hello Jock,


First, thank you for the time you spend analysing the Coriolis code and
that detailed report. I will try to make a comprehensive answer about why
Coriolis is the way it is. 

* My job description at the University is not only to develop Coriolis,
  but be the system admistrator of a Linux network (150 desktop &
  servers) and manage industrial ASIC toolchains (Cadence,Mentor,Synopys).
  So I usually can only spend 70% of my time on Coriolis.

* One problem in a tool like Coriolis is that you need three kind of
  skills to really be efficient:

  1. A good understanding of the specifics of making an ASIC.
  2. Algorithmic knowledge to tackle efficiently the problems in (1).
  3. Programming skills in at least two language C++ & Python,
     plus a bit of software engineering.

  So, I have knowledge in all three, but cannot became a top notch
  expert in all of them. This also makes it difficult to have interns.

* In some parts, namely the detailed router, the algorithm is a genuine
  one, developing and testing it is a full time job by itself. It is not
  even finished yet. But, when finished it will allow lots of fancy things
  like seamless analog/digital designs and taking into account fancy
  constraints to avoid side-channel attacks on crypto chips (for example).

* It has a past... Some decisions where taken more than 10 years ago in
  a diffrent context and I simply cannot afford to rewrite the software
  every times something shift.

* Nevertheless, I'm deeply commited to write software as cleanly as possible,
  and will make improvements when I can. So I will very carefully read your
  observations. But, unless you want to commit yourself for the next ten years,
  I need a code that I intimately understand.


> Detailed version (The Rant)
> ===========================
> 
> 1. Installation
> 
> Coriolis 2 can be built and installed two ways:
> 
>   a) inside the home directory (“Fixed directory tree”), using a helper script [1],
>   b) as a package, either RPM or DEB [2].
> 
> I followed the (a) route, and it actually went well except for a couple
> of quirks, that is considering the number of dependencies. As I
> understand, the (b) way is not well maintained for now.

  Coriolis is too unstable yet. Using packages would meant to rebuild them
  at every git push, and having the users do not forget to reinstall it
  afterwards. I think Staf Verhaegen is making some trials.
    Ruben Undheim, an official Debian packager, is making DEB of Coriolis,
  you may contact him to see if you can set up some continuous integration
  there.
    My goal is to have something "stable" after the november run in 180nm.


> The method (a) can be used per se, at least on Debian GNU/Linux, or
> within chroot or LXC environments.
> 
> Unfortunately, the Python extensions are coupled with the rest of the
> Coriolis, so it is impossible to use the advantages of 'virtualenv' or
> similar environments with Coriolis.

  I'm not familiar with virtualenv and I don't understand how the
  C++ Python modules can be separated from the Python extension themselves.

> Thus, entering the development with Coriolis for pythonistas is
> complicated by the combination of two factors:
> 
> - lack of native packages for their OSes,
> - lack of PyPI package or pip/virtualenv support.
> 
> I understand that Coriolis is a niche product, so we can not really
> expect much in terms of packaging for popular OSes. So it may be better
> for Coriolis to take another route:
> 
> - decouple Python extensions from the main product,
> - provide Python extensions as a pip package (via PyPI or git),
> - supply a script and/or instructions for building the main product
> with the pip package.

  Breaking things in multiple components introduce complexity that you
  must manage afterwards. I can see a lot of troubles when people will
  have mismatched versions of the C++ core and the PyPI extensions.
  And lots of nigthmarish debug problems.
    Native packages would be better, and can be done, once it is stable
  enough.
  

> This is actually not a unique approach. For example, xapian-haystack
> ships a script for building a whole Xapian search engine (C++) in
> PYTHONPATH [3].
> 
> 2. Documentation
> .
> All the basics are covered by Coriolis User's Guide [4] (general
> workflow and GUI) and Python Tutorial [5], that are available online
> and offline, in PDF and HTML formats.
> 
> Unfortunately, Coriolis Python API don't have its own reference guide.
> There is a good reference on Hurricane C++ API [6] though. Since Python
> API just copies the C++ API (which is a terrible desicion by itself,
> see the explanation in 3.2), this reference alone has the great part of
> both C++ and Python APIs covered. But other parts of the Python API
> (most importantly, Etesian and Katana) stays undocumented beyond the
> basics.

  For Etesian & Katana, this is just due to the lack of time. Also mixed
  with a lack of stability. It is very frustrating to write a doc which
  is no longer relevant three month later. The basic doc of Katana is
  in fact in Kite. Kite is the digital only version of the router while
  Katana is the mixed one. And it is in flux, so I postponed the port
  of the doc.
  


> 3. API
> 
> 3.1. Supported Python versions
> 
> The Coriolis Python API is a Python 2 extension.
> 
> Python 2.7 was released in 2010, and it was meant to be the last 2.x
> release back then. In the following years Python 2 had no new features
> other than backports from Python 3. As of January 2020 Python 2 is
> considered unsupported by PSF. [7]
> 
> Still clinging to outdated and abandoned language and not even having a
> (publicly available, at least) transition plan seems a bit scary to me.

  I understand very well. I'm not clinging to it, I just have had not time
  yet to make the transition. If nothing unexpected happens I hope to do
  the migration sometimes in the next three monthes. Here I must admit
  I'm not proud of the way the C++/Python wrapper is written, but it do
  works exactly like I want to... Here again with lots of unusual constraints
  that I see no way to make swig or the like to understand.


> 3.2. Best practices of Python APIs
> 
> To have a new API mimic the old API written in another programming
> language seems like an excellent idea at first. You don't have to
> design anything. Don't have to think of naming. You can reuse
> documentation and tests. The new API is easy to use, if you already got
> used to the old one. Everybody's happy, right?
> 
> Well, everybody except the end users whom the new API is created for.

  Not so fast here, we need a definition of "end users". In my lab,
  the people using Coriolis are mostly ASIC people, that is electrical
  engineers. They use the minimal and simplest possible subset of any
  programming language.
    You may look at the relationship between C++ and SystmeC. SystemC
  is comparable to nMigen but under the form of a C++ library. They
  don't event tell them it's C++. SystemC is usually presented as a
  language on it's own (sometimes they talk about C).
    In fact, and this is a trend I've seen emerge with the rise of FPGA
  for some time, you have *two* kind of audience.
  
  * Electrical engineers or guys comming "from the hardware", with limited
    programming skills. They describe their design as series of blocks.
    They want to tightly control how and what they generate.
  * Computer Science types, or guys coming "from the software", with
    advanced programming skills. They tend to see their design in term
    of classes and functions, with lot of implicit mechanisms.
    Typical example is Chisel or SpinalHDL.

  At this point I have no clear answer about what the "best" language
  would be. But I can tell you for sure that many "hardware guys" are
  literally repelled by languages like Chisel.
    It's a discussion we are currently having at the lab. Like the one
  that did take place in this list a little while ago.
  

> Each programming language has its own best practices, and most of the
> time they either contradict the ones accepted by another language users
> or just don't have analogues in that language. Your new users will see
> your API as alien, cumbersome, or just poorly designed. They may have
> to cram their way around the least expected features. They may have to
> write wrappers around your API to reduce the astonishment factor [8]
> for the others. But most likely they will simply walk away.

  Another point to take into account, is that, at first, the Python
  extention was made to be able to do "rapid prototyping". That is
  quicly develop and test under Python, then, convert back to C++.
  So keeping both interfaces in synch as much as possible was to
  reduce that work.
    And, as if for myself only, I do constant back and forth between
  Python and C++, so I have one less "translation" to manage.
  

> Here I'll try to give a run-down of Coriolis API features that scares
> Python developers (“bad”) along with their attractive and comfy
> alternatives (“good”).
> 
> 3.2.1. Singletons
> 
> You don't need a special methods to create and access a unique object
> in Python, since you can just import it.
> 
> Bad: af = CRL.AllianceFramework.get()
> 
> Good: from CRL import af

  OK.
  

> 3.2.2. Getters and setters
> 
> Getters and setters are considered an antipattern (not only in Python),
> so they should be replaced by properties or collection-like interfaces.
> 
> Bad:
>   env = af.getEnvironment()
>   env.setCLOCK('^ck$|m_clock|^clk$')
> 
> Good:
>   af.env['CLOCK'] = '^ck$|m_clock|^clk$'

  OK. But introduce some rework at Python/C++ level.
  

> 3.2.3. Data types
> 
> Python use duck typing, so you should avoid any direct type indication
> or querying in Python.
> 
> Bad: Cfg.getParamInt('katana.vTracksReservedLocal').setInt(6)
> 
> Good: Cfg['katana.vTracksReservedLocal'] = 6

  The Cfg module is a shame. Is is unecessarily separated from the rest
  and the only one using boost. Creating one of the most painful
  dependency only for it.
    As those variables are created then stored in C++, I need to be
  able to guess their type right. integer, float, sometimes enum,
  and percentage... If you can show me an elegant solution, I will
  take it.
  

> 3.2.4. Syntactic sugar
> 
> It's easier to account for the certain things that goes in pairs
> (open/close, create/destroy) with context managers or decorators.
> 
> Bad:
>   UpdateSession.open()
>   do_my_thing()
>   UpdateSession.close()
> 
> Good:
>   with UpdateSession():
>       do_my_thing()
> 
> Also good in some cases:
>   @update_session
>   def do_my_thing():
>       ...

  OK. I will look into that.


> 3.2.5. Self-documenting
> 
> Python have a built-in 'help()' function, that returns a docstring for
> a given object. Python C extensions can emulate a docstring for use
> with 'help()'. Static syntax checkers and IDEs also rely on this API.
> 
> It is very important that this emulated docstring contains not only the
> description of the function or method, but also a signature (parameters
> and return value) in reST format, as recommended by PEP287 [9], or in
> older Epytext format at worst. This will greatly facilitate the use of
> Python C extension with modern IDEs.
> 
> The rules have slightly changed since Python 3.4, but the idea remains.

  The main reason here is still the lack of time. But there may be
  another problem. My python interface allow to mirror in Python
  the C++ function overload, but Python only allows one set of
  parameters, is that true or I'm lagging on Python features again?
  So how to describe a function with more than one parameter set?
  

> 3.2.6. Naming conventions
> 
> The Python API must adhere to naming conventions accepted in Python. I
> can not stress enough the importance of this point, but let us address
> the styling issues in general in 3.3.
> 
> 3.3. Styling
> 
> I have to admit that Coriolis Python style is quite consistent, but it
> looks like the only purpose of this consistency is to contradict the
> PEP 8 [10] in any possible way. [11]
> 
> You might think that style is not that important, but after 15 minutes
> spent in search of the 'ChipRoute' class definition, diagnosing and
> restarting IDE, checking Moon phase and whatnot, find that 'ChipRoute' 
> is not a class, but a module… How well the end user could perform with
> that in mind?

  Quite the opposite, I do think style is important. The goal of style
  is readability and it is mine. But I don't think you can say that there
  is *one* good style and all others are bad. And even the reference style
  may evolve... It is easy to slip from "the style I'm accustomed to" and
  "the right style". I understand the advantages of using a style shared
  by many peoples, but I won't blindly comply (I'm both French and a bit
  stubborn). I will try to find time to read the PEP8, but I have a lot
  of work to do...
    I've already seen this debate about C++ coding, and there are
  definetely good and bad styles (or lack of) but I won't say there is
  "the good style". Among good styles, there are different tradeoffs
  that may or may not suits you.

 
> Another thing is that it's nearly impossible to lure a junior developer
> into a project that neglects styling. In modern development,
> proprietary and opensource alike, an ability to write a consistent,
> readable, uniform code is very much appreciated, and junior developers
> expect to acquire good professional habits in their first projects. And
> style is the first thing they learn to distinguish in someone else's
> code.

  Maybe it has changed in the company world, but for what I've seen
  in the ASIC world, code cleanliness is still a long way home...
  But again, it may be different company we are talking about.
  I talk of Cadence/Mentor/Synopsys, if you have the opportunity,
  take a look.

  A last reflexion about PyCharm, it is very well for people working
  only on Python code. But for my part, I edit C++, C, Python, ReST,
  cmake, LaTeX, Yaml and whatnot, so I use Emacs (vim could also do).
  It would be inefficient to have one IDE/editor per language.

  
  Anyway, this is very valuable input, and I will take it into
  account as soon as I can, given my current workload.


  Best regards,
  

> [1] http://coriolis.lip6.fr/pages/users-guide.html#id16
> [2] http://coriolis.lip6.fr/pages/users-guide.html#id19
> [3] https://github.com/notanumber/xapian-haystack
> [4] http://coriolis.lip6.fr/pages/users-guide.html
> [5] http://coriolis.lip6.fr/pages/python-tutorial.html
> [6] http://coriolis.lip6.fr/doc/hurricane/index.html
> [7] https://www.python.org/dev/peps/pep-0373/
> [8] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> [9] https://www.python.org/dev/peps/pep-0287/
> [10] https://www.python.org/dev/peps/pep-0008/
> [11] 
> 
https://www.opensourceshakespeare.org/views/plays/play_view.php?WorkID=hamlet&Act=2&Scene=2&Scope=scene&LineHighlight=1307#1307


-- 

      .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
      /v\     Jean-Paul.Chaput@lip6.fr
    /(___)\   work: (33) 01.44.27.53.99              
     ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip

[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sat, Mar 28, 2020 at 4:45 PM Jean-Paul Chaput
<Jean-Paul.Chaput@lip6.fr> wrote:

>   The main reason here is still the lack of time. But there may be
>   another problem. My python interface allow to mirror in Python
>   the C++ function overload, but Python only allows one set of
>   parameters, is that true or I'm lagging on Python features again?
>   So how to describe a function with more than one parameter set?

ah.

right.  with all the other things, i am going to focus on this one.
it is a major, serious failing in the ENTIRETY of the free software
community to COMPLETELY fail to comprehend this one, absolutely
critical thing.

microsoft DCOM got it right (co-classes).  as a result i was the ONLY
PERSON IN THE WORLD - i checked, emailing the IEXPLORE developer and
he kindly replied - to use the full power of IEXPLORE.DLL DCOM
bindings from python-comtypes.  and by "full power" i mean "all 300
objects, all 2,000+ functions, and all 20,000 properties".

the only reason that was possible - including the c++ functions which
had multiple overloads - was because of a property of DCOM called
"co-classes".

when the Mozilla Foundation decided "oh!  we!  know!  we!  will copy!
DCOM!  and call it! XPCOM!  it'll be great!" they did NOT copy
co-classes, and consequently fucked EVERYONE around for the next 15
years who tried to develop third party xulrunner applications.

even activestate - a major supporter of firefox technology- eventually
went "fuckit" and used webkit for their products.

eventually, with "everyone abandoning xulrunner", the Mozilla
Foundation further fucked everyone about by *abandoning* xulrunner
entirely, themselves, despite the fact that yes, there were people
actually using it.  this actually resulted in a hard fork of xulrunner
(which, sadly, does not have co-classes added to it).

there is actually one feature-complete implementation of microsoft
DCOM... get ready for this... in wine!  yes, really: wine has a
*complete* implementation of DCOM, to the point where you can actually
install python and python win32 comtypes *under Wine* and actually use
it!

however the barrier to entry when compiling applications using the
wine-under-linux system (executables get named MYAPP.EXE.so and you
then have to run that using winetricks....) would just blow the tops
of already-overloaded ASIC engineers overheated heads.


so whatever you pick, Jean-Paul, please be aware of two things:

1. this is a HARD problem, not properly acknowledged or recognised by
the open source community, and it's been pissing me off for 20 years.

2. whatever you choose to do, please for god's sake don't choose
wrong.  the amount of pain that you will encounter will make boost
look like a sunday christmas dinner and birthday party all rolled into
one.

so if you *have* successfully mirrored multiple c++ function-overloads
into python, GREAT!  congratulations, you are amongst an absolute tiny
minority of programmers who have comprehended this, where the majority
are in systematic pathological failure and mental melt-down.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jean-Paul Chaput]

[-- Attachment #1.1: Type: text/plain, Size: 3271 bytes --]

On Sat, 2020-03-28 at 17:13 +0000, Luke Kenneth Casson Leighton wrote:
> On Sat, Mar 28, 2020 at 4:45 PM Jean-Paul Chaput
> <Jean-Paul.Chaput@lip6.fr> wrote:
> 
> >   The main reason here is still the lack of time. But there may be
> >   another problem. My python interface allow to mirror in Python
> >   the C++ function overload, but Python only allows one set of
> >   parameters, is that true or I'm lagging on Python features again?
> >   So how to describe a function with more than one parameter set?
> 
> ah.
> 
> right.  with all the other things, i am going to focus on this one.
> it is a major, serious failing in the ENTIRETY of the free software
> community to COMPLETELY fail to comprehend this one, absolutely
> critical thing.
> 
> microsoft DCOM got it right (co-classes).  as a result i was the ONLY
> PERSON IN THE WORLD - i checked, emailing the IEXPLORE developer and
> he kindly replied - to use the full power of IEXPLORE.DLL DCOM
> bindings from python-comtypes.  and by "full power" i mean "all 300
> objects, all 2,000+ functions, and all 20,000 properties".
> 
> the only reason that was possible - including the c++ functions which
> had multiple overloads - was because of a property of DCOM called
> "co-classes".
> 
> when the Mozilla Foundation decided "oh!  we!  know!  we!  will copy!
> DCOM!  and call it! XPCOM!  it'll be great!" they did NOT copy
> co-classes, and consequently fucked EVERYONE around for the next 15
> years who tried to develop third party xulrunner applications.

  Funny, I remember well a student a while ago telling me that
  I should use XUL to write the graphical interface of Coriolis.
  I was already feeling like an old shmuck with my Qt... 


> so if you *have* successfully mirrored multiple c++ function-overloads
> into python, GREAT!  congratulations, you are amongst an absolute tiny
> minority of programmers who have comprehended this, where the majority
> are in systematic pathological failure and mental melt-down.

  I did write it a long time ago, it is too complicated for what it
  does. You can see an example in the PyHorizontal.cpp file and
  look at PyHorizontal_create(). It is very dumb and tedious
  programming. I intend to review it thoroughly when migrating
  to Python 3. Basically it build the "signature" of the function
  and is followed by a big "if" afterwards.
    The Python "wrapper" is not something I'm very proud of as it
  is only a big bunch of C macros. I'm not happy with the *way*
  the code is generated, but on the other hand, I am happy with
  the *generated* code and the fact that I can finely tune it.
  I will try to make a more intensive use of C++ templates.
  But not as much as in Boost as it becomes very, very slow to
  compile (it's the reason why the Qt team abandoned it in favor
  of another interface generator).

-- 

      .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
      /v\     Jean-Paul.Chaput@lip6.fr
    /(___)\   work: (33) 01.44.27.53.99              
     ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip

[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Tue, Mar 31, 2020 at 9:17 AM Jean-Paul Chaput
<Jean-Paul.Chaput@lip6.fr> wrote:
>
> On Sat, 2020-03-28 at 17:13 +0000, Luke Kenneth Casson Leighton wrote:

>   Funny, I remember well a student a while ago telling me that
>   I should use XUL to write the graphical interface of Coriolis.
>   I was already feeling like an old shmuck with my Qt...

sadly, in retrospect, it would have turned out to be a huge mistake.
i'm sorry to have to be the bearer of bad news, that i have been
unable to find *any* major libre software team with the intelligence
and resources to comprehend the strategic importance of DCOM.

historically, it is not a coincidence that there is a correlation
between microsoff's massive success (and that they used COM) and
Apple's massive success (and that they used Objective-J, Objective-C
and Objective-M), where each of those had - has - the same co-class
capability of COM actually built-in to the *compilers*, providing all
and any binaries right across the board with the exact same run-time
self-describing self-introspective object-orientated capacity that COM
gives.

hm.

that said, for long-term plans, you *might* want to look at GNU
Objective-C and the GNUstep GUI framework.
https://en.wikipedia.org/wiki/Objective-C#GNU,_GNUstep,_and_WinObjC

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

and pyobjc:
https://pyobjc.readthedocs.io/en/latest/changelog.html

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] pyobjc, gnu objective-c and gnustep

[Luke Kenneth Casson Leighton]

https://groups.google.com/forum/#!topic/gnu.gnustep.discuss/6QbWfmaMrck
patches - 8 years ago (damnit, the changelog for 2.0.1 removed it)

you see the sort of thing i mean?  there *are* people who understand
the power of dynamic objective runtime self-describing capability: and
they're *never properly funded*.

On Tue, Mar 31, 2020 at 10:32 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> and pyobjc:
> https://pyobjc.readthedocs.io/en/latest/changelog.html

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] pyobjc, gnu objective-c and gnustep

[lkcl .]

*click* what the hell am i saying??  jean-paul, we've got a clear need
for improvements to coriolis2, it is *really* easy to justify putting
in an application for NLNet funding, here.

if you're interested, i can kick some tires and see if there are
people in, say, the GNUStep community (and other locations) willing to
get pyobjc GNUStep support properly working, upstreamed, and suitable
for use as the main "glue" in coriolis2.  replacing libboost as well
as Qt [1]

what do you think?

l.

[1] once pyobjc python bindings exist and work, you'd have *immediate*
dynamic runtime access to GNUStep GUI Objective-C bindings.  aalllll
of theeeeem.  GNUStep GUIs in python using pyobjc would be laughably -
and very unnervingly - trivial.  oh and there's a high probability
that they'd also work on macosx, unmodified.

On Tue, Mar 31, 2020 at 10:38 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> https://groups.google.com/forum/#!topic/gnu.gnustep.discuss/6QbWfmaMrck
> patches - 8 years ago (damnit, the changelog for 2.0.1 removed it)
>
> you see the sort of thing i mean?  there *are* people who understand
> the power of dynamic objective runtime self-describing capability: and
> they're *never properly funded*.
>
> On Tue, Mar 31, 2020 at 10:32 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >
> > and pyobjc:
> > https://pyobjc.readthedocs.io/en/latest/changelog.html

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] pyobjc, gnu objective-c and gnustep

[Jean-Paul Chaput]

[-- Attachment #1.1: Type: text/plain, Size: 3118 bytes --]


On Tue, 2020-03-31 at 11:42 +0000, lkcl . wrote:
> *click* what the hell am i saying??  jean-paul, we've got a clear need
> for improvements to coriolis2, it is *really* easy to justify putting
> in an application for NLNet funding, here.

Hello Luke,

This is a complicated matter. As a team of one, I have limited resources,
so I must prioritize (and I know myself, I'm not very good at that).
Anyway, the short term goal is to have the 180nm circuit done and
working by October. In order to do that I/we must not "finish"
Coriolis, but put it to a point it can fulfil that objective.
I'm convinced it is doable, but we should go straight to the point,
because I'm sure that lots of unexpected issues will pop-up and
I will have to tackle them quickly.

My "development cycle" are alternate steps of "adding features" then
"improve code at constant features".

So, having more hands will really be a plus (as you already proposed in
an early mail). The problem is to have someone(s) with that triple skills
(ASIC, algorithmic, software) and it has been proven difficult on my
end. To have an example of the kind of code I get, you could take a
look to the whole capacitor stuff in coriolis/oroshi/python/
(and you will easily see where I modified the code with my unique
 coding style). This was made by a good electrical engineer, but
with embryonic software knowledge. The code is to draw the layout
of one or a matrix of analog capacitors. The comments are made for
doxygen.

And besides, all of our students have already chosen their internship
(in the industry). I think we may have a good one in June.
And lastly, due to the Covid-19 and University shutdown we cannot
hire anybody, should we have a candidate.

I absolutely do not want to give you the impression that I do not
want more people working on Coriolis, quite the contrary.
But I want to expose the context as rightfully as it is.
The question being how to circumvent those initial conditions
to get more efficient people working on Coriolis?

I've taken a look at GNUstep, it seems a bit quite by there...
(maybe I was on the wrong site). For the record, WidowMaker is
one of the more memory efficient window manager I have ever seen
(still can work on my UltraSparc 1 / NetBSD).

However I will remove Boost as soon as possible, it has proven to
be a pebble in my shoes for too long. And migrating towards Python3.

I'm currently making my Python code a bit more PEP8 compliant then
backporting some of the work of Jock in soclayout. *But* I will keep
some style that you may find bad. Paradox is that the "comma" at the
start of line was showed to me by an early Python adopter back around
2000...


Best regards,
-- 

      .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
      /v\     Jean-Paul.Chaput@lip6.fr
    /(___)\   work: (33) 01.44.27.53.99              
     ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip

[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] pyobjc, gnu objective-c and gnustep

[lkcl .]

On Tue, Mar 31, 2020 at 3:11 PM Jean-Paul Chaput
<Jean-Paul.Chaput@lip6.fr> wrote:
> On Tue, 2020-03-31 at 11:42 +0000, lkcl . wrote:
> > *click* what the hell am i saying??  jean-paul, we've got a clear need
> > for improvements to coriolis2, it is *really* easy to justify putting
> > in an application for NLNet funding, here.
>
> Hello Luke,
>
> This is a complicated matter. As a team of one, I have limited resources,
> so I must prioritize (and I know myself, I'm not very good at that).
> Anyway, the short term goal is to have the 180nm circuit done and
> working by October.

yes absolutely.  i wanted to think slightly beyond that.

> some style that you may find bad. Paradox is that the "comma" at the
> start of line was showed to me by an early Python adopter back around
> 2000...

sigh yes that was when i started using python.  it predates common
usage of PEP8.

best,

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] pyobjc, gnu objective-c and gnustep

[Jacob Lifshay]

On Tue, Mar 31, 2020, 07:30 lkcl . <luke.leighton@gmail.com> wrote:

> On Tue, Mar 31, 2020 at 3:11 PM Jean-Paul Chaput
> <Jean-Paul.Chaput@lip6.fr> wrote:
> > some style that you may find bad. Paradox is that the "comma" at the
> > start of line was showed to me by an early Python adopter back around
> > 2000...
>
> sigh yes that was when i started using python.  it predates common
> usage of PEP8.
>

This is one of the reasons I like Rust: because they use the same
consistent code style nearly everywhere and they have a tool (rustfmt) that
automatically thoroughly formats everything in that style. Additionally,
beginners are encouraged to use it. Even if there are some things I would
do differently if I were designing the code style today, having consistency
across all Rust code everywhere is a big enough benefit that I can live
with some things that aren't quite how I like.

I've had to deal with the gazillion different styles of C and C++ languages
and teaching materials that actively try to get beginners to come up with
their own style to their detriment. All it does is makes their code harder
to read.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sat, Mar 28, 2020 at 4:45 PM Jean-Paul Chaput
<Jean-Paul.Chaput@lip6.fr> wrote:

>   Anyway, this is very valuable input, and I will take it into
>   account as soon as I can, given my current workload.

i really meant it, Jean-Paul, we have some budget available from NLNet
to be able to help get some people in to help you out, here, ok?

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sat, Mar 28, 2020 at 4:45 PM Jean-Paul Chaput
<Jean-Paul.Chaput@lip6.fr> wrote:
> > 3.2.3. Data types
> >
> > Python use duck typing, so you should avoid any direct type indication
> > or querying in Python.
> >
> > Bad: Cfg.getParamInt('katana.vTracksReservedLocal').setInt(6)
> >
> > Good: Cfg['katana.vTracksReservedLocal'] = 6

sorted.  jean-paul feel free (after jock's review and highly likely
automatic reaction to put code-comments in it) to cut/paste the Config
class into coriolis2 somewhere.

hypothetically it's possible to create a nested pseudo-class which
does away with the need for the conversion of "." to "_" however i
honestly feel it's overkill: underscore looks perfectly fine to me.

btw please do fix the spelling of "edgelength" :)  at least provide
both names for the same param?


https://git.libre-riscv.org/?p=soclayout.git;a=commitdiff;h=81283a7462a0623cb8b5f603be5fd96117595081
https://git.libre-riscv.org/?p=soclayout.git;a=blob;f=experiments7/utils.py;h=60057f63810942bcfce160234db1c9eafe0ba5ba;hb=81283a7462a0623cb8b5f603be5fd96117595081#l320
https://git.libre-riscv.org/?p=soclayout.git;a=blob;f=experiments7/doAlu16.py;h=1c1b61605ec9422ce9e88af57501fdbe6d9ac197;hb=81283a7462a0623cb8b5f603be5fd96117595081#l17

  17 def coriolis_setup():
  18     with Config(Cfg.Parameter.Priority.UserFile) as cfg:
  19         cfg.misc_catchCore = False
  20         cfg.misc_info = False
  21         cfg.misc_paranoid = False
  22         cfg.misc_bug = False
  23         cfg.misc_logMode = True
  24         cfg.misc_verboseLevel1 = True
  25         cfg.misc_verboseLevel2 = True
  26         cfg.etesian_effort = 2
  27         cfg.etesian_spaceMargin = "20.0%"
  28         cfg.etesian_aspectRatio = "100.0%"
  29         cfg.etesian_uniformDensity = True
  30         cfg.anabatic_edgeLenght = 24
  31         cfg.anabatic_edgeWidth = 8
  32         cfg.anabatic_topRoutingLayer = 'METAL5'
  33         cfg.katana_searchHalo = 30
  34         cfg.katana_eventsLimit = 1000000
  35         cfg.katana_hTracksReservedLocal = 7
  36         cfg.katana_vTracksReservedLocal = 6
  37
  38         env = af.getEnvironment()
  39         env.setCLOCK('^clk$|m_clock')
  40         env.setPOWER('vdd')
  41         env.setGROUND('vss')

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jock Tanner]

Luke,

I think this code won't always work as intended:

            p = Cfg.getParamInt(attr) # all params have a type
            if p.type == 'Enumerate':
                Cfg.getParamEnumerate(attr).setInt(val)
            else:
                Cfg.getParamInt(attr).setInt(val)

If the parameter named 'attr' is already defined, 'p.type' will be set
according to its type. But for undefined parameters 'p.type' will be
what we ask for, i. e. always 'Int'.

BTW I think it is useless to have a distinction between 'Int' and
'Enumerate' types, as well as between 'Double' and 'Percentage'. But
it's another thing.

On Sat, 2020-03-28 at 23:16 +0000, Luke Kenneth Casson Leighton wrote:
> On Sat, Mar 28, 2020 at 4:45 PM Jean-Paul Chaput
> <Jean-Paul.Chaput@lip6.fr> wrote:
> > > 3.2.3. Data types
> > > 
> > > Python use duck typing, so you should avoid any direct type
> > > indication
> > > or querying in Python.
> > > 
> > > Bad: Cfg.getParamInt('katana.vTracksReservedLocal').setInt(6)
> > > 
> > > Good: Cfg['katana.vTracksReservedLocal'] = 6
> 
> sorted.  jean-paul feel free (after jock's review and highly likely
> automatic reaction to put code-comments in it) to cut/paste the
> Config
> class into coriolis2 somewhere.
> 



_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sun, Mar 29, 2020 at 2:23 PM Jock Tanner <tanner.of.kha@gmail.com> wrote:
>
> Luke,
>
> I think this code won't always work as intended:
>
>             p = Cfg.getParamInt(attr) # all params have a type
>             if p.type == 'Enumerate':
>                 Cfg.getParamEnumerate(attr).setInt(val)
>             else:
>                 Cfg.getParamInt(attr).setInt(val)
>
> If the parameter named 'attr' is already defined, 'p.type' will be set
> according to its type. But for undefined parameters 'p.type' will be
> what we ask for, i. e. always 'Int'.

yes i'm assuming that etesian.something is already pre-defined, and
can be detected as being of type "Enumerate".

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Jock Tanner]

Hello Jean-Paul,

Thank you for such a thorough answer. I'd be happy to help without
taking too much of your time. I understand that you have a huge piece
of work at your hands. It's great that other people getting themselves
involved in Coriolis.

On Sat, 2020-03-28 at 17:44 +0100, Jean-Paul Chaput wrote:
>   I'm not familiar with virtualenv and I don't understand how the
>   C++ Python modules can be separated from the Python extension
> themselves.

>   Breaking things in multiple components introduce complexity that
> you
>   must manage afterwards. I can see a lot of troubles when people
> will
>   have mismatched versions of the C++ core and the PyPI extensions.
>   And lots of nigthmarish debug problems.
>     Native packages would be better, and can be done, once it is
> stable
>   enough.

virtualenv is a great asset for Python developer, and it strongly
influences the ways that Python software is shipped. I'll try to
elaborate.

When building native packages we usually think of Python interpreter
itself and required Python modules as system-wide dependencies with all
the version restrictions that comes out of it. When our dependencies
are few and their versions most probably matching those packaged for
the OS, it's OK. When the Python-related part of the project grows,
version mismatches becomes a hindrance.

But Python is better than that! CPython itself with all its built-in
components is totally independent of its position in the OS directory
tree. It relies on its own, mostly FHS-compliant, directory tree, which
is defined in runtime by PYTHONPATH environment variable. So
'virtualenv' and similar tools are created to manage multiple
PYTHONPATH trees on user level, switch between them, aid pip with
installing packages on them et c.

If Python package can be installed in virtual environment, it becomes
totally independent of system-wide Python packages and even the Python
interpreter itself (using pyenv). It is very convenient for developers
and users alike. That is why Python bindings are usually decoupled of
their underlying programs or libraries. For example, lxml is installed
separately of libxml2 and libxslt, but totally depends on them
installed system-wide.

Another implication is PYTHONPATH being FHS-like, that means literally
every program can be built and installed in PYTHONPATH rather than
anywhere else. For example, uwsgi is a Python application server, that
has a CPython statically compiled into itself and thus could be shipped
as a native OS package. But their creators have chosen another
approach. They made it a pip package, and as such it relies on
PYTHONPATH and supports virtualenv just for the sake of conveniency.
Their pip package, in turn, can be included in any OS repository as a
Python package by independent supporters.

To summarize. If the project consists of a native part (C/C++) and a
dynamic part (Python with C bindings), and native part can be used
without dynamic part, then it makes sense to decouple them and package
them separately: native part − as an OS package or a build script, and
dynamic part − as the corresponding dynamic language infrastructure
(pip/setuptools) suggests. It would introduce some overhead, but also
add flexibility to the process.

But if native and dynamic parts are inseparable from each other, it is
better to just ship the whole thing as a pip package.

AFAIK these approaches are prevalent in Python software development.

>   Not so fast here, we need a definition of "end users". In my lab,
>   the people using Coriolis are mostly ASIC people, that is
> electrical
>   engineers. They use the minimal and simplest possible subset of any
>   programming language.
>     You may look at the relationship between C++ and SystmeC. SystemC
>   is comparable to nMigen but under the form of a C++ library. They
>   don't event tell them it's C++. SystemC is usually presented as a
>   language on it's own (sometimes they talk about C).
>     In fact, and this is a trend I've seen emerge with the rise of
> FPGA
>   for some time, you have *two* kind of audience.
>  =20
>   * Electrical engineers or guys comming "from the hardware", with
> limited
>     programming skills. They describe their design as series of
> blocks.
>     They want to tightly control how and what they generate.
>   * Computer Science types, or guys coming "from the software", with
>     advanced programming skills. They tend to see their design in
> term
>     of classes and functions, with lot of implicit mechanisms.
>     Typical example is Chisel or SpinalHDL.
> 
>   At this point I have no clear answer about what the "best" language
>   would be. But I can tell you for sure that many "hardware guys" are
>   literally repelled by languages like Chisel.
>     It's a discussion we are currently having at the lab. Like the
> one
>   that did take place in this list a little while ago.
>  =20

Both Chisel and SpinalHDL are syntactically derived from Scala. Scala
is a younger, a bit less scary sibling of Haskell. Haskell can scare
the shit out of every software engineer except those with strong
mathematical background. So I suggest it's not the best practices that
repells “hardware guys”, but a careless introduction to functional
approach in programming.

>   My python interface allow to mirror in Python
>   the C++ function overload, but Python only allows one set of
>   parameters, is that true or I'm lagging on Python features again?
>   So how to describe a function with more than one parameter set?

As a function with optional parameters.

What we have now:

  class Box(object):
      def __init__(self, *args, **kwargs): # real signature unknown
         pass

What we could have with only positional arguments:

  class Box(object):
      def __init__(self, x1=None, y1=None, x2=None, y2=None):
          """
          Creates a box of a given shape. If all parameters are
          omitted, creates an empty box.

          :param x1: starting horizontal offset,
          :param x1: starting vertical offset,
          :param x1:
horizontal limit,
          :param x1: vertical limit,
          :return:
Box object.
          """
          pass

This is as neat as it can be in Python 2, but it doesn't account for
Point or Box arguments. From Python perspective, the fact that the
first positional argument can be either a single coordinate, a point,
or a box means variable reuse, and it is bad for readability. But
nethertheless we can account for that in our docstring:

  class Box(object):
      def __init__(self, x1=None, y1=None, x2=None, y2=None):
          """
          Creates a box of a given shape. If all parameters are
          omitted, creates an empty box.

          :param x1: starting horizontal offset, or starting point,
                     or another box to copy,
          :param x1: starting vertical offset, or limiting point,
      
:param x1: horizontal limit,
          :param x1: vertical limit,
       
:return: Box object.
          """
          pass

With Python 3.4+ we could get much better results with typing module
and Union[]. But with Python 2 without mypy that's it.

>   Quite the opposite, I do think style is important. The goal of
> style
>   is readability and it is mine. But I don't think you can say that
> there
>   is *one* good style and all others are bad. And even the reference
> style
>   may evolve... It is easy to slip from "the style I'm accustomed to"
> and
>   "the right style". I understand the advantages of using a style
> shared
>   by many peoples, but I won't blindly comply (I'm both French and a
> bit
>   stubborn). I will try to find time to read the PEP8, but I have a
> lot
>   of work to do...
>     I've already seen this debate about C++ coding, and there are
>   definetely good and bad styles (or lack of) but I won't say there
> is
>   "the good style". Among good styles, there are different tradeoffs
>   that may or may not suits you.

I can't completely agree with you on this subject, Jean-Paul. While
other languages have different style guides that evolved significantly
during their lifetimes, PEP 8 is literally the one and only Python
style guide for the last 19 years, and it has never changed, only
extended once to account for new language features. Other style guides
(Google, Khan Academy) only extend PEP 8 and other PEPs, but never
overrule them.

>   Maybe it has changed in the company world, but for what I've seen
>   in the ASIC world, code cleanliness is still a long way home...
>   But again, it may be different company we are talking about.
>   I talk of Cadence/Mentor/Synopsys, if you have the opportunity,
>   take a look.

Can I really see the code you mention, or is it under NDA?

The first thing that came to mind was MyHDL [1]. I think their code is
quite clean and idiomatic.

>   A last reflexion about PyCharm, it is very well for people working
>   only on Python code. But for my part, I edit C++, C, Python, ReST,
>   cmake, LaTeX, Yaml and whatnot, so I use Emacs (vim could also do).
>   It would be inefficient to have one IDE/editor per language.

Speaking of JetBrains products, Pycharm is indeed not suited for C/C++
development. CLion, on the other hand, has a Python plugin that has all
the features of Pycharm CE, and also a first-class cmake support. I
tried CLion at a small C project, and it went perfect. But alas, CLion
is a non-free product. [2]

Now if I were tasked with setting up an environment for long-scale
hybrid C/C++/Python development I would try Eclipse with CDT and PyDev
plugins. It may lack a bit in features and usability, but it's free.

As for other formats like reST, JSON, LaTeX et c., all the IDEs handle
them well either out of the box or via plugins.

As for Emacs, I've read some posts [3] and watched some videos, and I
must say I'm not impressed. It may seem from the description that all
the plugins do a decent job, but the whole system completely lacks
consciousness, or you may call it multitasking abilities, and the
screen is very inexpressive. The editor just reacts on keystrokes, and
that's all. Like you're supposed to manually start syntax check, style
check, static analysis. Then fix problems and start again, and again.
It is really looks tedious, and boring, and error-prone.

On the contrast, when I open a file in Pycharm, it immediately starts
all the checks on it and gradually (it may take a second on a decent
machine) highlights all the real or possible problems in the
background. Critical things are bright red. Syntax errors.
Uninitialized variables. Unresolved imports. Non-criticals are pale
yellow or greyish. Call arguments not matching callee's signatures.
Variables that may be uninitialized. Unused code. Style problems. Human
language syntax errors.

I can scroll, type, switch between files, and still I see all the
results of this background work simultaneously.

Eclipse's PyDev can also do static check while you type [4], but the
list of possible warnings seems shorter than Pycharm's, and the result
is less esthetically pleasing for my taste.

So, Jean-Paul, I would really like you to try either IDE on a real code
and tell me what you think.

[1] https://github.com/myhdl/myhdl/
[2] 
https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000477130-How-to-handle-a-mixed-Python-C-C-project
[3] https://www.fullstackpython.com/emacs.html
[4] https://www.pydev.org/manual_adv_code_analysis.html



_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sun, Mar 29, 2020 at 11:46 AM Jock Tanner <tanner.of.kha@gmail.com> wrote:
> On Sat, 2020-03-28 at 17:44 +0100, Jean-Paul Chaput wrote:
> >   At this point I have no clear answer about what the "best" language
> >   would be. But I can tell you for sure that many "hardware guys" are
> >   literally repelled by languages like Chisel.
> >     It's a discussion we are currently having at the lab. Like the
> > one
> >   that did take place in this list a little while ago.
> >  =20
>
> Both Chisel and SpinalHDL are syntactically derived from Scala. Scala
> is a younger, a bit less scary sibling of Haskell. Haskell can scare
> the shit out of every software engineer except those with strong
> mathematical background. So I suggest it's not the best practices that
> repells “hardware guys”, but a careless introduction to functional
> approach in programming.

that, and the fact that the rocket-chip developers (from Berkeley)
claimed to "reduce code size significantly" in the two following ways:

1. pretty much absolutely f***-all in the way of comments.
2. make heavily depth-nested use of classes and mix-ins [with ZERO
documentation].

the first major exposure to a real-world industry-class processor
written with the Chisel system, and it's one of the worst (best)
introductions on how *never* to write (un)maintainable (un)useable
code i've seen in 43 years of programming, with the exception of some
hilarious perl and php scripts.

i'd _really like_ to give you good examples of code written in Chisel: i can't.

the more important thing, than Chisel, is, as Jock points out: scala
simply isn't popular.
https://www.infoworld.com/article/3270626/python-scala-climb-the-ranks-of-language-popularity.html

http://pypl.github.io/PYPL.html
scala remains at 0.97% - less than one percent - by way of how pupular
language tutorials are searched for.

python on the other hand is *right at the top* - with a whopping 30%.

so i know you picked SpinalHDL for vexriscv:
https://github.com/SpinalHDL/VexRiscv

however, i would be particularly interested to hear your thoughts on,
for example this:
https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/MulSimplePlugin.scala

versus this:
https://github.com/lambdaconcept/minerva/blob/master/minerva/units/multiplier.py

just on an *instinctive* level, which one is easier to read?

from a style perspective: *six* levels of indentation-bracing?
really??  and using "=" to indicate type-declaration (val
aSigned,bSigned = Bool), where every other language uses it for
assigmnent?  and the "implicit return result" by assigning to a
variable with the same name as the function?  i mean, they should have
made it more difficult than that.

it's just... flat-out.... NO.  anyone writing code in this language is
*deliberately* making their life hell, and, worse, if the chip becomes
a commercial success (or an academic success) the insanely high
barrier to entry will make it extremely costly to find programmers.

... lesson learned? :)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Immanuel, Yehowshua U]

It sounds like Coriolis Python-C++ API isn’t the best. I know this isn’t super easy to do, even with help from tools like Swig.

HOWEVER, given that we have direct access to Jean Paul - that’s a big benefit at the moment.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sun, Mar 29, 2020 at 5:05 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> It sounds like Coriolis Python-C++ API isn’t the best. I know this isn’t super easy to do, even with help from tools like Swig.
>
> HOWEVER, given that we have direct access to Jean Paul - that’s a big benefit at the moment.

basically, yes.  the alternatives (which do exist) are... inconvenient
(language-wise), and we don't have a working relationship with them.
and, it's 20 years old, and silicon-proven.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Michael Nolan]

On 3/26/20 5:03 PM, Luke Kenneth Casson Leighton wrote:
>
> if you prefer just reply to this message with a paragraph or two and i
> will cut/paste it?
>
> l.

The decoder we have is based on that of IBM's [microwatt reference
design](https://github.com/antonblanchard/microwatt). Because
microwatt's decoder is quite regular, consisting of a bunch of large
switch statements returning fields of a struct, we elected not to
pursue a direct conversion of the VHDL to nmigen. Instead, we
extracted the information in the switch statements into several CSV
tables, and leveraged nmigen to construct the decoder from these
tables. We applied the same technique to extract the subfields
(register numbers, branch offset, immediates, etc.) from the
instruction, where Luke converted the information in the POWER ISA
specification to text, and wrote a module in python to extract those
fields from an instruction.

To test the decoder, we initially verified it against the tables we
extracted, and manually against the power ISA specification. Later
however, we came up with the idea of verifying the decoder against the
output of the GNU assembler. This is done by selecting an instruction
type (integer reg/reg, integer immediate, load store, etc), and
randomly selecting the opcode, registers, immediates, and other
operands. We then feed this instruction to GNU AS to assemble, and
then the assembled instruction is sent to our decoder. From this, we
can then verify that the output of the decoder matches what was generated
earlier.

We also explored using a similar idea to test the functionality of the
entire SOC. By using the [QEMU](https://www.qemu.org/) powerpc
emulator, we can compare the execution of our SOC against that of the
emulator to verify that our decoder and backend are working correctly.
We would write snippets of test code (or potentially randomly generate
instructions) and send the resulting binary to both the SOC and
QEMU. We would then simulate our SOC until it was finished executing
instructions, and use Qemu's gdb interface to do the same. We would
then use Qemu's gdb interface to compare the register file and memory
with that of our SOC to verify that it is working correctly. I did
some experimentation using this technique to verify a rudimentary
simulator of the SOC backend, and it seemed to work quite well.


_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sat, Mar 28, 2020 at 6:07 PM Michael Nolan <mtnolan2640@gmail.com> wrote:

> The decoder we have is based on that of IBM's [microwatt reference
> design](https://github.com/antonblanchard/microwatt). Because

fantastic, threw it in the mix.  you actually have git clone
read/write access to this
https://git.libre-riscv.org/?p=crowdsupply.git;a=summary
could you see if you can throw in a couple more links or so, at least
one to the source code?  i added one to the isatables page.

oh btw i am mowing my way through the pseudo-code sections of the
PDF... going cross-eyed here..

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Mar 28, 2020 at 6:07 PM Michael Nolan <mtnolan2640@gmail.com> wrote:
>
> On 3/26/20 5:03 PM, Luke Kenneth Casson Leighton wrote:
> >
> > if you prefer just reply to this message with a paragraph or two and i
> > will cut/paste it?
> >
> > l.
>
> The decoder we have is based on that of IBM's [microwatt reference
> design](https://github.com/antonblanchard/microwatt).

spotted the links, thanks michael.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Immanuel, Yehowshua U]

> * yehowshua if you could write a paragraph or two about CREATE-X

Hi Luke,

Crowd Supply Update
=================

Yehowshua is a student at Georgia Tech currently pursuing a Masters in Computer Engineering - to graduate this summer. He had started working on LibreSOC in December and wanted to to get LibreSOC more funding so I could work on it full time.

He originally asked if the ECE Chair at Georgia Tech would be willing to fund an in-department effort to deliver an SOC in collaboration with LibreSOC(an idea to which he was quite receptive). Through Luke, Yehowshua got in contact with Chistopher Klaus who suggested Yehowshua should look into Klaus's startup accelerator program Create-X and perhaps consider taking LibreSOC down the startup route. Robert Rhinehart, who had funded LibreSOC a little in the past also suggested that Yehowshua incorporate LibreSOC with help from Create-X and said he would be willing to be a seed investor. All this happened by February.

As of March, Yehowshua has been talking with Robert about what type of customers would be interested in LibreSOC. Robert is largely interested in biological applications. Yehowshua also had a couple meetings with Rahul from Create-X. Yehowshua has started the incorporation of LibreSOC. The parent company will probably be called Systèmes-Libres with LibreSOC simply being one of the products we will offer. Yehowshua also attended HPCA in late February and had mentioned LIbreSOC during his talk. People seemed to find the idea quite interesting

He will later be speaking with some well know startup lawyers in have an HQ in Atlanta to discuss business related things such as S Corps, C corps, taxes, wages, equity etc…

Yehowshua plans for Systèmes-Libres to hire full time employees. Part time work on Libre-SOC will still be possible through donations and support from NL Net and companies like purism.

Currently, Yehowshua plans to take the Create-X summer launch program and fund Systèmes-Libres by August. Full time wages would probably be set around 100k USD.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Immanuel, Yehowshua U]

> He will later be speaking with some well know startup lawyers in have an HQ in Atlanta to discuss business related 

** that have
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Sun, Mar 29, 2020 at 4:14 AM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> Yehowshua is a student at Georgia Tech currently pursuing a Masters in Computer Engineering - to graduate this summer. He had started working on LibreSOC in December and wanted to to get LibreSOC more funding so I could work on it full time.

added.  robert's given us permission to mention his support of our
project.  i implicitly understood that due to his high-profile online
presence that i couldn't say that he had been supporting us,
particularly with the ZC706 and the improvements to vga_lcd.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

build servers.
https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/023_2020mar26_decoder_emulator_started.mdwn;h=1fd0606f9a2be89dd2393cf569b87211092724fb;hb=3e5f9725d044001aceaf95482fcc101bdfa854ad#l785

could someone write something about the build servers?

thx.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

jacob the example's a bit big, it's the kind of thing that would be
great in its own update (which we move it to) with a full explanation.
could you put it in an "example" file in a repo somewhere, link to it,
and say "we'll do an update about the IR later"?

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] name change announcement on crowdsupply

[Jacob Lifshay]

On Tue, Mar 31, 2020 at 11:15 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> jacob the example's a bit big, it's the kind of thing that would be
> great in its own update (which we move it to) with a full explanation.
> could you put it in an "example" file in a repo somewhere, link to it,
> and say "we'll do an update about the IR later"?

I moved the example code to the Kazan repo.

I did notice that we *forgot* to announce we changed our name from
Libre-RISCV to Libre-SOC on any crowdsupply updates -- we should do
that and change the crowdsupply description page to match.

I also updated the latest update to consistently spell Libre-SOC the
way we decided on: Libre-SOC.

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] name change announcement on crowdsupply

[Jacob Lifshay]

On Tue, Mar 31, 2020 at 6:51 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
> I did notice that we *forgot* to announce we changed our name from
> Libre-RISCV to Libre-SOC on any crowdsupply updates -- we should do
> that and change the crowdsupply description page to match.

we should also update our page on NLNet.

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] name change announcement on crowdsupply

[Luke Kenneth Casson Leighton]

On Wed, Apr 1, 2020 at 2:51 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Tue, Mar 31, 2020 at 11:15 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >
> > jacob the example's a bit big, it's the kind of thing that would be
> > great in its own update (which we move it to) with a full explanation.
> > could you put it in an "example" file in a repo somewhere, link to it,
> > and say "we'll do an update about the IR later"?
>
> I moved the example code to the Kazan repo.

great

> I did notice that we *forgot* to announce we changed our name from
> Libre-RISCV to Libre-SOC on any crowdsupply updates -- we should do
> that and change the crowdsupply description page to match.

that'll be tricky, the url has to stay the same.  changing
description, yes should be ok.

> I also updated the latest update to consistently spell Libre-SOC the
> way we decided on: Libre-SOC.

ah good.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] name change announcement on crowdsupply

[Jacob Lifshay]

On Wed, Apr 1, 2020, 03:58 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Wed, Apr 1, 2020 at 2:51 AM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
>
> > On Tue, Mar 31, 2020 at 11:15 AM Luke Kenneth Casson Leighton
> > <lkcl@lkcl.net> wrote:
> > >
> > > jacob the example's a bit big, it's the kind of thing that would be
> > > great in its own update (which we move it to) with a full explanation.
> > > could you put it in an "example" file in a repo somewhere, link to it,
> > > and say "we'll do an update about the IR later"?
> >
> > I moved the example code to the Kazan repo.
>
> great
>
> > I did notice that we *forgot* to announce we changed our name from
> > Libre-RISCV to Libre-SOC on any crowdsupply updates -- we should do
> > that and change the crowdsupply description page to match.
>
> that'll be tricky, the url has to stay the same.  changing
> description, yes should be ok.
>

Wouldn't it work for the old url to just redirect to the new one? We can
ask if they support that.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] name change announcement on crowdsupply

[Luke Kenneth Casson Leighton]

On Wed, Apr 1, 2020 at 6:31 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> Wouldn't it work for the old url to just redirect to the new one? We can
> ask if they support that.

will get a chance soon.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Cole Poirier]

On Mar 31 2020, at 11:09 am, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

> build servers.
> https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/023_2020mar26_decoder_emulator_started.mdwn;h=1fd0606f9a2be89dd2393cf569b87211092724fb;hb=3e5f9725d044001aceaf95482fcc101bdfa854ad#l785
> 
> could someone write something about the build servers?
> 
> thx.
> 
> l.

Sure I'll put in a short blurb and Jacob can add to it if he thinks it
necessary. Do I have the necessary access to the crowdsupply git repo?

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Cole Poirier]

On Mar 31 2020, at 11:35 am, Cole Poirier <colepoirier@gmail.com> wrote:
> On Mar 31 2020, at 11:09 am, Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
>> could someone write something about the build servers?
>> 
>> thx.
>> 
>> l.
> 
> Sure I'll put in a short blurb and Jacob can add to it if he thinks it
> necessary. Do I have the necessary access to the crowdsupply git repo?
> 
> Cole

Sorry it turns out I don't have push access to the crowdsupply repo.
Luke, may I request push access to the crowdsupply repo. I remember that
in an email a few days ago you told I should give you a name for the
repo I want created for the environment setup scripts. Can you create
and also grant me push access to a repository named dev-env-setup?
Unless you can think of a more appropriate name.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Wednesday, April 1, 2020, Cole Poirier <colepoirier@gmail.com> wrote:

> On Mar 31 2020, at 11:35 am, Cole Poirier <colepoirier@gmail.com> wrote:
> > On Mar 31 2020, at 11:09 am, Luke Kenneth Casson Leighton
> > <lkcl@lkcl.net> wrote:
> >> could someone write something about the build servers?
> >>
> >> thx.
> >>
> >> l.
> >
> > Sure I'll put in a short blurb and Jacob can add to it if he thinks it
> > necessary. Do I have the necessary access to the crowdsupply git repo?
> >
> > Cole
>
> Sorry it turns out I don't have push access to the crowdsupply repo.
> Luke, may I request push access to the crowdsupply repo.


ok.


> I remember that
> in an email a few days ago you told I should give you a name for the
> repo I want created for the environment setup scripts. Can you create
> and also grant me push access to a repository named dev-env-setup?
> Unless you can think of a more appropriate name.


nope sounds great.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] extremely busy crowdsupply update started

[Luke Kenneth Casson Leighton]

On Wed, Apr 1, 2020 at 11:08 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

>>
>> Sorry it turns out I don't have push access to the crowdsupply repo.
>> Luke, may I request push access to the crowdsupply repo.
>
>
> ok.


done just edit the .git/config file change the url to one that
includes gitolite3.

>>
>> I remember that
>> in an email a few days ago you told I should give you a name for the
>> repo I want created for the environment setup scripts. Can you create
>> and also grant me push access to a repository named dev-env-setup?


done also.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev