[Libre-soc-bugs] [Bug 523] demo program needed showing register dependencies

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=523

--- Comment #4 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #3)
> (In reply to Jacob Lifshay from comment #2)
> > What do you think of writing it in Rust? That would have several benefits:
> > 
> > + We can pretty easily build an interactive Web version using WebAssembly
> > and Rust's tooling for the web. No server-side stuff would be needed, other
> > than file hosting. I'm thinking type command line arguments into a text box
> > and it dynamically regenerates an html table, nothing too fancy.
> 
> the capabilities are compelling, i was also wondering if it would be
> beneficial
> to do an interactive version.

I was thinking we'd just host the interactive version on our website, making it
extremely easy to use.

I was also thinking we'd have a few other CPU models included for comparison
purposes, such as the standard register-renamed model, and a simple in-order
pipeline.

> > + As a future extension, it could be easily integrated with
> > power-instruction-analyzer to make a full-featured cycle-accurate (not just
> > instruction accurate) simulator, where Rust's speed would be a huge
> > advantage over Python.
> 
> here's the thing jacob: as we have a low-to-medium priority short-medium
> requirement (increasing to high over the long-term) to be an "educational
> resource", rust's complex installation, learning curve and low adoption rate
> compared to a whopping 30% world-wide adoption and "single-binary-download"
> for python, it puts itself outside of the running.
> 
> imagine that LibreSOC became a study project for a secondary school, or that
> someone aged 15 with a raspberry pi wanted to learn how it worked.  just the
> installation process for rust is *so advanced* compared to python's simple
> installation that they'd literally get nothing done before giving up
> entirely.

assuming it's a recent version of Raspbian, "sudo apt install cargo" should
work.

> (to give you some idea, there: my brother dan helped his daughter, from age
> 15, to complete programming assignments by using "online embedded web"
> versions of python on her chromebook)

There's an official online version of Rust: https://play.rust-lang.org/
It has the top 100 most popular crates and their dependencies installed.

> python is just "step 1 click-and-download step 2 install step 3 get source
> step 4 run script" (and for the online web versions it's even simpler than
> that)

Well, my housemate spent several hours trying to figure out how to install it
on Windows, I had to go help him get pip working.

> rust is "step 1 click-and-download step 2 install step 3 wait for it to get
> and build dependencies step 3 get source step 4 compile source step 5 wait
> for it to get build dependencies step 6 run binary"

Rust is (assuming Windows) step 1 download installer, step 2 run installer
following prompts, step 3 download source code, step 4 open command prompt,
step 5 run "cargo run", step 6 read output.

If your on Linux it's even easier (assuming you have binutils already): step 1
run installer following prompts, step 2 download source, step 3 run cargo run,
step 4 read output.

Or, if you like, just run "sudo apt install cargo" (also automatically installs
binutils), download source, run "cargo run".

> 
> back to the technical requirements: cycle-accurate simulators do not take
> into account the latency or overlap inside of pipelines (which is the object
> of the exercise, here).  the assumption made by a cycle-accurate simulator
> is that the instruction "will at least complete in exactly one cycle,
> transparently and independently of the underlying micro-architecture".
> 
> i.e. a cycle-accurate simulator models enough so that binaries have the
> exact same behaviour and guarantees of hardware *but* that at the end of
> single-stepping the entire "machine state" - including memory including
> caches and VM PTEs, is 100% up-to-date (not compromised as it would be by
> some JIT emulators for example)
> 
> consequently, modelling the instruction stages and associated latency is not
> something that ever goes into a cycle-accurate simulator because doing so
> massively slows it down and unnecessarily complicates the design.

Well, I think we're using the same term to mean different things.

> bottom line is that the code for this exercise (even in rust) would be
> inappropriate for use as a "true" simulator, which is why i mentioned that
> it should not actually perform the actual execution of the instructions (or
> store any state needed to do so).

I beg to differ: having something that can quickly calculate exactly how fast a
certain program (potentially very large program -- on the scale of billions of
instructions executed) would run on our processor is hugely valuable, that
allows us to do benchmarking to determine which algorithms work best, it also
allows us to easily determine the performance implications of changing
different aspects of our design without having to run a slow gate-level
simulation. It also allows testing without the need to actually implement a
change in nmigen, since most features are much harder to write in nmigen than
in Rust.

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