
RISC-V from scratch 2: Hardware layouts, linker scripts, and C runtimes - pplonski86
https://twilco.github.io/riscv-from-scratch/2019/04/27/riscv-from-scratch-2.html
======
PaulHoule
RISC-V, System/360 for the 2020s!

~~~
microcolonel
Indeed, though I think people here think you're saying that as an insult
rather than a compliment.

~~~
PaulHoule
Yep.

The real genius behind the 360 was scalablity. Not only could you buy a wide
range of different sized machines, but IBM has kept making better 360s to this
day.

Intel has accomplished the same with the 8086 (by accident more than design)
and so has ARM.

Once you get past the x86 and ARM the price/performance ratio gets a lot
worse. Thus you end up with expensive WiFi routers that allegedly can work as
a file server but can't really handle it, or things like the Samsung
Smartthings hub that has to offload even simple things to the AWS cloud.

RISC-V could make the market for embedded chips competitive again. RISC-V
scales even more than the 360 did since you can put in just the features you
want, thus you might be able to build something which is high performance but
doesn't waste a transistor on features you don't want.

~~~
microcolonel
> _Samsung Smartthings hub that has to offload even simple things to the AWS
> cloud_

Doubly disappointing considering how much money Samsung has sunk into Joyent
(though maybe it's not the same division of Samsung, and that's why they don't
use it).

> _RISC-V could make the market for embedded chips competitive again. RISC-V
> scales even more than the 360 did since you can put in just the features you
> want, thus you might be able to build something which is high performance
> but doesn 't waste a transistor on features you don't want._

Crucially, I think, it lacks any unusual or frivolous features, so it is
virtually free of surprises. For example, it's little endian because little
endian won (because it is better).

~~~
MayeulC
> For example, it's little endian because little endian won (because it is
> better).

Could you elaborate on this? My understanding is that Little Endian was
introduced to enable some optimizations on low-level mathematical operations
or fetch operations. However, as the block size for ram operations increased,
together with the transistor count, it was IIRC shown (I can't find a
reference) that there were little advantages in using one or the other
(different optimizations being possible in either). I tend to prefer Big
Endian, as it is closer to our numerical representation, and the network
order.

Saying that Little Endian has "won" could be justified if you only look at
x86, but I wouldn't call that the whole story.

~~~
microcolonel
I used to like big endian for the same reason (that it seems more similar to
our written numeral conventions), but little endian allows you to narrow and
widen integers with no operations, and without changing the pointer. That's
why it's better in my view.

------
tindleaj
Exciting writeup! Looking forward to reading this later.

