
RISCVEMU: 128 bit RISC-V emulator - ingve
http://bellard.org/riscvemu/
======
rwmj
Unfortunately it can't boot the Fedora/RISC-V[1] disk image out of the box
because the supplied Linux kernel doesn't have all the config enabled[2] for
systemd to run properly :-(

It gets as far as the "Welcome to Fedora 25 (Twenty Five)!" banner but then
gives a bunch of systemd errors around "Function not implemented". inotify
seems to be the main one.

[1]
[https://fedoraproject.org/wiki/Architectures/RISC-V](https://fedoraproject.org/wiki/Architectures/RISC-V)

[2] [https://github.com/rwmjones/fedora-riscv-
kernel/blob/master/...](https://github.com/rwmjones/fedora-riscv-
kernel/blob/master/config)

~~~
ajross
The serious answer might be that a hardware RISC-V deployment is very unlikely
to be running Fedora in production. All the existing planned devices are MCUs
which are much too small (and lack MMUs in many cases).

The more glib one is that if you're interested in building a CPU emulator from
source but don't want to rebuild a kernel, you're probably skipped a few
important skills along the way.

~~~
rwmj
Fedora is targeting 64 bit server-class hardware, which is on its way -- in
production as we speak.

I'm quite capable of rebuilding the kernel, just lazy. The main problem is
that the kernel is embedded in the bootloader, and the bootloader for this
emulator is patched because the RISC-V HTIF [obsolete device] emulation is
different from the other RISC-V implementations, which makes rebuilding the
whole thing somewhat tedious.

~~~
BuuQu9hu
> in production as we speak

Really?! Got a link? I thought the ISA was still in flux, isn't it a bit early
to be making hardware?

~~~
rwmj
Follow the links in:
[https://news.ycombinator.com/item?id=13213342](https://news.ycombinator.com/item?id=13213342)
and have a look at the latest workshop proceedings:
[https://riscv.org/2016/12/5th-risc-v-workshop-
proceedings/](https://riscv.org/2016/12/5th-risc-v-workshop-proceedings/)

The user-level ISA is fixed. The privileged-level ISA is in flux, but people
obviously think there's enough there to make real hardware. To be fair the
main problems with the privspec are to do with virtualization, and likely the
first crop of hardware won't support that or will have only interim support.

------
ksec
Does anyone know where does Fabrice Bellard work for his day job?

~~~
sasvari
He used to work for Netgem [0], and according to his French wikipedia page [1]
he co-founded Amarisoft where he is listed on their about page [2]:

 _Amarisoft

We are delighted to bring some affordable tools and software to the 4G mobile
community to unleash creativity and at the end expand communications among
people. Accessible technology is the basement of possible success story. We at
Amarisoft are working on helping all size of company or individuals being a
player in mobile networks of now and future generation. We hope you'll enjoy
the opportunity.

[..]

Fabrice Bellard

Fabrice is a computer programmer who is best known as the creator of the
FFmpeg and QEMU software projects. He studied at Ecole Polytechnique,
specializing at Telecom Paris in 1996. Fabrice is an amazing person bringing
creativity to the whole team._

[0]
[https://news.ycombinator.com/item?id=2557422](https://news.ycombinator.com/item?id=2557422)

[1]
[https://fr.wikipedia.org/wiki/Fabrice_Bellard](https://fr.wikipedia.org/wiki/Fabrice_Bellard)

[2] [http://www.amarisoft.com/?p=about](http://www.amarisoft.com/?p=about)

~~~
wsc981
He is one of the most genius programmers of our time, for sure. He achieved so
many great things in his career. More than most people achieve in life. See:
[https://en.wikipedia.org/wiki/Fabrice_Bellard](https://en.wikipedia.org/wiki/Fabrice_Bellard)

------
jdub
Don't judge it too much by the speed of the JavaScript demo. The (host) native
emulator is ridiculously fast.

~~~
raverbashing
Considering it's a RISC emulator running on top of an x86 emulator running in
JS, the slowness is perfectly understandable

But when running the 128bit demo I get a funny value for sqrt(2) in fp64 mode:
1.728102266788482

------
apaprocki
It would be nice to add the 64- and 128-bit DFP (Decimal Floating Point)
support to this. The Intel DFP library can be dropped in, similar to how
SoftFP was used for floating point: [https://software.intel.com/en-
us/articles/intel-decimal-floa...](https://software.intel.com/en-
us/articles/intel-decimal-floating-point-math-library)

The RISC-V spec mentions it supports this in the “L” Standard Extension for
Decimal Floating-Point.

~~~
kobeya
There's no actual spec.

Although there is discussion about creating one if you want to join the ISA-
dev mailing list.

~~~
ajross
There certainly is:
[https://riscv.org/specifications/](https://riscv.org/specifications/)

I read it about a year ago and found it straightforward and clean.

Are you making a technical point about stuff missing?

~~~
kobeya
I'll wait while you go and actually read the "L" section of the spec you
linked to.

~~~
ajross
Got it. You were indeed making a technical point and chose snark over clarity.
Thanks.

~~~
Dylan16807
I thought it was clear that "there's no actual spec" referred to decimal and
not risc-v as a whole. It's an important non-nitpick point.

~~~
nitrogen
I don't [edit: think] "there is no spec [for the CPU]" was an unreasonable
interpretation for that comment, even if "[for decimal floating point]" was
the intended meaning.

~~~
Dylan16807
There was some ambiguity, and the interpretation is understandable.

Dismissing it as a "technical point" and implying that kobeya never should
have commented is not.

~~~
nitrogen
Yes, that is also true.

------
arethuza
I suspect the in-browser version of this running Linux is probably
considerably more powerful than the machine I first used Unix on - an HLH
Orion.

------
progman
Fabulous work! Is there a way to change the size of the disk image? Or do I
have to bake a new one, according to Yocto/OpenEmbedded RISC-V Port for
instance?

[https://github.com/riscv/riscv-poky](https://github.com/riscv/riscv-poky)

------
0xcde4c3db
He quietly updated both the source tarball and the disk image after this story
was posted (from "2016-12-18" to "2016-12-19"). It looks like there were
mostly some changes to the block device code.

~~~
0xcde4c3db
The disk image has been updated again, to "2016-12-19.1".

------
faragon
Fabrice Bellard is a genius.

------
wyldfire
He's done so much work on QEMU I would just naturally assume it would be
included there. Why create a separate emulator?

~~~
bonzini
Fabrice is not active in QEMU anymore (and has not been fur almost 8 years
now).

Without having looked at the code, I would guess that it wasn't worth the
effort of being the first 128-bit target on a core that is based on JIT
compilation and supports 32-bit hosts.

------
EvgeniyZh
No github/bitbucket/gitlab/etc.?

~~~
beefman
I think this is an interesting question. Does Bellard use a VCS?

~~~
bonzini
QEMU used svn, but that was when everybody did, so don't judge him from that.
:-)

------
dom0
Bellard strikes again :)

------
Annatar
I understand that designing processors is fun, but I hold several things
against RISC-V:

\- the assembler dst, src backward syntax (like intel);

\- the fact that this processor design is being aggressively pushed here
(featured several times already);

\- the fact that the instruction set is non-orthogonal (32-bit fixed encoding
makes the decoder simple, but creates the same load-store problem as on SPARC
- hello non-existent, synthetic instructions!);

\- the fact that they could have extended the open source UltraSPARC T-series
design, but decided to just re-invent the wheel all over again. How does
128-bit support justify starting from scratch, and not re-using what is
already there and open sourced?

The last point is their biggest sin, in my view. There is already an open
source processor design, and a good, solid design, and they just went ahead
and invented their own anyway. All the lessons about reuse went out of the
window. We're the only industry that I know of that keeps nuking itself and
starting from scratch, throwing away all the work which had been done before.

Oh, and I seriously dislike the instruction mnemonics. To the authors of
RISC-V:

couldn't you have made the mnemonics MC68000 compatible, or at least make them
similar?

~~~
rwmj
To address a couple of these points:

\- Assembler syntax is a matter of personal preference. I also loved
programming the 68K, writing OS-9/68k drivers back in 1990. However the vast
majority of even kernel/embedded programmers rarely touch assembler these
days.

\- SPARC & register windows. A very unfortunate design choice in hindsight.
The RISC-V ISA developers have paid very close attention to existing designs,
and other ISAs and microarchitectures are frequently referenced. Have a look
at the discussions on the ISA-Dev mailing list:
[https://groups.google.com/a/groups.riscv.org/forum/#!forum/i...](https://groups.google.com/a/groups.riscv.org/forum/#!forum/isa-
dev)

\- RISC-V is trying to avoid patents, so they cannot necessarily reuse
existing ISAs, even open ones.

~~~
popgoescarrot
Based on your behavior in this comment thread -- downvoting comments that give
valid criticism of the RISC-V ISA -- I have to conclude that the reason the
RISC-V folks chose not to reuse a patent-unencumbered ISA such as SH2 or
MIPS32 (minus the unaligned load-store instructions) is simple vanity.

~~~
bonzini
What does _your_ comment add to the discussion, and what is the proof of what
you are attributing to the user?

