[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 #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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.

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

(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)

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)

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"


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.

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

its sole focus is, then, to generate the tables done by hand.

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