[libre-riscv-dev] Migen Conversions and Update

[Luke Kenneth Casson Leighton]

On Wed, Jan 2, 2019 at 1:49 PM Hendrik Boom <hendrik at topoi.pooq.com> wrote:
>
> 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.

 you should see the book "Design of a Computer" by J Thornton.  it's
absolutely, absolutely fascinating.  core memory for goodness sake!
individual ALUs made from enormous PCBs stuffed with transistors!  a
ring bus that *literally* goes round an entire room!

 and yet it was a superscalar out-of-order execution engine with
register renaming, and as such was literally the precursor to all
modern computers today.

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

 well.... they didn't really have IEEE-754 back in 1964 :)

> I appreciate that you are planning on supporting smaller data.

 yes - down to IEEE754 16-bit

> But these objections have little to do with the kind of internal
> hardware architecture you're discussion here.

 and there are significant modernisations and augmentations, since.

 one thing that really needs to be done is a simulator of the
scoreboard arrangement, particularly some of the augmentations.

l.