[libre-riscv-dev] next tasks

[Jacob Lifshay]

On Thu, Mar 12, 2020, 23:43 Lauri Kasanen <cand at gmx.com> wrote:

> On Thu, 12 Mar 2020 10:40:16 -0700
> Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> > If we decide to create our own simulator, it might be a good idea to
> write
> > it in rpython or similar since that has an optimizing JIT trace compiler
> > that can effectively speed up any interpreter/simulator. That's what's
> used
> > to implement PyPy -- it's basically just a python interpreter written in
> > rpython.
> >
> > If we decide we don't want rpython, then I would suggest Rust -- I've
> > already started writing a cycle-accurate CPU simulator to test out my
> idea
> > for making a spectre-proof cpu (I stopped since it was taking longer
> than a
> > few days):
> >
> https://salsa.debian.org/Kazan-team/spectre-resistant-speculative-processor
>
> Using a standard language would beat slightly improved speed, for the
> usual reasons. The hipster languages have trouble running in many
> settings,


I can agree that rpython sounds like it is probably a pain to set up,
however I've found Rust to be utterly trivial to set up on all Linux
systems I've tried (other than termux -- the distro designed to run on top
of Android -- and even there it was relatively easy):

assuming you've already installed build-essential (needed for the linker),
just install using the one-line command on https://rustup.rs/ then build &
run the project by running:

cargo run -- <args to my program>

or to build and run the program independently from cargo:

cargo build
target/debug/<program-name> <args to my program>

and we need people to be able to modify the simulator (e.g.
> me).
>

Ok. fair point.

I'd recommend learning Rust anyway since Kazan (the graphics driver) is
written in Rust, as well as some of the other code.

Additionally, I find Rust to be just as (or more) expressive as modern C++
and it has additional benefits such as the compiler proving that your code
doesn't have undefined behavior (very handy for when you would have 100kloc
of C++ code that occasionally inexplicably segfaults -- been there), a very
powerful traits system (think C++ template metaprogramming but more
extensible and harder to misuse), and a waay better macro system than C
including stuff like procedural macros (running custom code at compile time
to generate source code).

Also, Rust has a very nice standard build system/package manager (cargo),
it's much better than C and C++'s build system mess.

I found Rust to be relatively easy to understand coming from my background
of >7 years of C++ and C.

If the simulator was written in hipster language of the week, I may
> not even be able to get it running, and it would place a significant
> obstacle on my modifying it. More than a decade in C/C++ vs learning an
> entirely new language with all its quirks.
>
> It would likely present similar barriers to others who need to modify
> it.
>

I had picked rpython and Rust as possible languages since python and rust
are already extensively used in the Libre-SOC codebase.


> (why yes, I have bad experiences with python, ruby, rust, go...)


hope they weren't like my experience with Scala -- never got anything to
build after several hours of trying and the JVM is huge.

Jacob