Re: no networking in riscv-qemu... use pppd?
On Wed, Apr 19, 2017 at 7:23 PM, Michael Clark <michaeljclark@mac.com> wrote:
>> On 20/04/2017, at 3:56 AM, Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com> wrote:
>> Do you think that all RV64G hardware, at least the one able to run a
>> general purpose OS ("not embedded"), will also support C?
>
> Yes I believe RV64GC will be standard for general purpose RV64 silicon.
> I believe that is why it has now been enabled as the default in the RV64
> toolchain. Much like all ARMv7 support Thumb2.
my $0.02 worth of logic, which i believe may be implicitly and
independently understood yet quite likely that literally everyone will
come to the same conclusion as you is:
* 32-bit risc socs are typically going to be low-power, low-cost,
very small. they're going to be the most cut-down that can possibly
be achieved. adding C would therefore be debatable.
* 64-bit risc: with 32-bit covering the low-end, what the heck would
you be doing making a 64-bit low-end (sub 200mhz) SoC for? no.
64-bit is for 700mhz, 1ghz, 1.5ghz and even 2ghz in 28nm. you want
speed, you want performance, you want performance/watt. C gives that
extra edge, good article here: https://arxiv.org/abs/1607.02318
> The code density is part of the attractiveness of RISC-V versus
> x86_64 and AArch64. x86 is very dense.
this _used_ to be a great selling point... for the intel 4004, 8086
... up to the 80486 and early pentiums. memory was *horrendously*
expensive, and x86 is known world-wide for having as you say the most
dense (highest level of escape-coding) instruction set ever
developed... ok ok possibly with the exception of one system i heard
of in the 1960s which was bit-based and you could do a ticker-tape
bootstrap loader in 21 *bits* (not bytes - *bits*). that was really
important when you had to do the switches and the clock by hand, from
power-on )
RISC goes the other way, cuts all the crap. the decode engine of x86
has to run much MUCH faster in order to give you the same equivalent
clockrate of RISC... power is a square law... translation: intel's
dead in the water... but hasn't really noticed it yet (too much cash
reserves: tens of billions).
> RISC-V with RVC is more dense.
> RISC ISAs like MIPS and SPARC have typically been hampered by code size. It eats up icache bandwidth.
yeahhh it's one of the downsides of RISC, that. so *any*
compression is good. efficient easily-decoded compression even more
so.
>> I think that it'll depend on the people implementing the hardware, and
>> that the Foundation doesn't have much say on that, unless they try and
>> have the power to strongarm companies into always implementing C.
>
> Well. I for one won't run an RV64G distro or buy RV64G hardware, only RV64GC. So count one less user. I'll have to figure out how to set up an auto builder if you all choose RV64G.
>
> The first tiny RISC-V silicon available to consumers has C although it is RV32IMAC (-march=rv32imac -mabi=ilp32 might be a good choice for a 32-bit distro assuming runtime hard float dispatch is sorted out and -march=rv64imafdc -mabi=lp64d for a 64-bit distro).
>
> BTW The images for RISCVEMU are RV64GC, as a datapoint. QEMU supports C also.
>
> If we build RV64GC then we set the benchmark.
very good point... and something i would say, y'know what? be bold:
work it out, and go for it. but doo keep everyone informed... just in
case :)
and that's really why i'm here, because i'm investigating getting
riscv 64-bit silicon made. these kinds of assessments and decisions
are things i *really* need to know about.
it would be the absolute stupidest thing to create hardware that came
out in 18 months and it was like, "tadaaa! here you go! real
hardware!" and the reaction was like, "uhhhnnn.... we optimised all
the compiler toolchain and packages for something completely
different, maaan." that would be bad :)
l.
Reply to: