[libre-riscv-dev] Migen Conversions and Update

Hendrik Boom hendrik at topoi.pooq.com
Wed Jan 2 13:49:09 GMT 2019


On Wed, Jan 02, 2019 at 03:45:52AM -0800, Jacob Lifshay wrote:
> On Tue, Jan 1, 2019, 22:51 lkcl <lkcl at libre-riscv.org wrote:
...
...
> >  :)  yeahh the problem is that everything has to be a python function:
> > there is no ternary operator in python, it's done syntactically:
> >
> >  x = 5 if (y > 3) else 2
> >
> > which is a pain in the ass.  for "standard" operations - add, mul,
> > compare etc - python has class-based functions __add__, __mul__,
> > __gt__, __ge__ etc. which will be called whenever the corresponding
> > python operator is used.
> >
> > there just... doesn't happen to be an __ternary__ over-ride, which is
> > a significant oversight.
> >
> I personally think not having an overridable ternary operator is part of
> good language design because it reduces unexpectedness (functions evaluate
> all there parameters, the ternary op does not).

Yes, the important difference in the so-called ternary operator isn't 
that it's ternary; it's that it doesn't evaluate all its arguments.
This has all kinds of implications in code generation and optimisation.

...
...

> >
> >  i *really* like the CDC 6600, particularly the enhancements that
> > mitch alsup made.  i must send you his unpublished book chapters:
> > we're free to use them as long as we give mitch credit.

I hated the CDC architeture as a user.  The main problems were that the 
huge word size was simply wrong for most of the work I had to do, and 
that the floating-point had strange behaviour.

I appreciate that you are planning on supporting smaller data.

As for floating point, it's unacceptable to have two numbers that 
compare equal, but whose squares don't compare equal.  I'm glad that 
that notation isn't used any more.

But these objections have little to do with the kind of internal 
hardware architecture you're discussion here.
 
...
...
> 
> I have a small preference for using a statically-typed language I'm
> familiar with, like C++ or Rust rather than a duck-typed language that I
> have no sizable experience with (Python), but I'll be fine.

Familiarity and strong static typing are both quite valuable.
I'm not suggesting changing languages in midstream, but I'd like to 
point out that static typing is compatible with duck typing.  Go (which 
you should look up as golang on google to avoid confusion with a common 
English word) manages an interesting synthesis of the two.  Static duck 
typing.

-- hendrik



More information about the libre-riscv-dev mailing list