RISC-V from scratch 2: Hardware layouts, linker scripts, and C runtimes(twilco.github.io)
twilco.github.io
RISC-V from scratch 2: Hardware layouts, linker scripts, and C runtimes
https://twilco.github.io/riscv-from-scratch/2019/04/27/riscv-from-scratch-2.html
22 comments
RISC-V, System/360 for the 2020s!
Indeed, though I think people here think you're saying that as an insult rather than a compliment.
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.
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.
> Thus you end up with expensive WiFi routers that allegedly can work as a file server but can't really handle it
I have one of those expensive wifi routers, and I'm pretty sure the issue is not the hardware, but terrible programming. It also has a torrent download feature, which also completely fails at accomplishing anything it claims to be able to do.
That being said, I'm also happy to see the excitement around RISC-V. I'm all for open platforms.
I have one of those expensive wifi routers, and I'm pretty sure the issue is not the hardware, but terrible programming. It also has a torrent download feature, which also completely fails at accomplishing anything it claims to be able to do.
That being said, I'm also happy to see the excitement around RISC-V. I'm all for open platforms.
I think that "terrible programming" usually involves the Linux NFS kernel server, Samba, etc.
> 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).
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).
> 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.
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.
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.
On some level i don't mind aws, I have a bastion in us-east-2 and it is only 35ms away. Still, it adds to the Rube Goldberg aspect of my smart home that the route between my light switch and my light goes through Ohio.
My practical beef is that if the net goes down, things stop working. Also it looks as if AMZN is cloning the SmartThings infrastructure, learning from the mistakes that SmartThings made earlier.
My practical beef is that if the net goes down, things stop working. Also it looks as if AMZN is cloning the SmartThings infrastructure, learning from the mistakes that SmartThings made earlier.
That's an interesting take on the subject. Personally, my "smart" appliances run on a closed Wi-Fi network, disconnected from the internet (the access point is a raspberry pi, which itself is connected to the rest of the network). I wouldn't trust any of these not to phone home, and everything can work offline if needs be.
I tend to prefer open-source compatible solutions (such as broadlink devices with python-broadlink), but my understanding is that the Amazon ecosystem is a closed "walled garden" one. Are you confident enough in Amazon to trust that your products will continue working in the future? Are you really willing to lose your lights in case of an internet outage?
I tend to prefer open-source compatible solutions (such as broadlink devices with python-broadlink), but my understanding is that the Amazon ecosystem is a closed "walled garden" one. Are you confident enough in Amazon to trust that your products will continue working in the future? Are you really willing to lose your lights in case of an internet outage?
Could you elaborate? What is the connection between IBM System/360 and RISC-V?
I definitely wasn't around then, but Fred Brooks talks about it in some of his writing, and the System/360 work is cited by his Turing award.
My understanding is that before System/360, software was tied to particular machines, which were naturally of a particular speed and capacity (and such resources were a very big deal back then).
When institutions bought new machines, they would MANUALLY REWRITE their software in the assembly language of the new machine. In other words, they were like manual compilers.
I think a lot of the compilers were actually specific to the machine as well! The hardware manufacturers invented their own programming language for their own machines. Portability wasn't a "thing". Many institutions probably only owned a 1 or 3 computers from the same manufacturer anyway.
So basically System/360 was a single instruction set for a lot of different machines, with differing speed and capacity. So you didn't have to do this thing that seems crazy to us today -- you could run the same software on may machines.
Software back then was really just an extension of hardware... The views have changed a lot [1]
Also from what I'm reading, the notion of an "abstract" machine was also not really a thing. There's a conceptual leap from a physical machine on your department's floor to some binary interface you can program against abstractly (the ISA), which we take for granted today.
https://amturing.acm.org/award_winners/brooks_1002187.cfm
Bob Evans promoted IBM’s vision to develop a single product line of general purpose computers with a common instruction set that permitted customers to preserve their investment in software as the moved from slower machines to faster ones. Evans assigned Brooks to lead the team to design this product line, called the System/360, which was announced in 1964. Brooks coined the term “computer architecture” to mean the structure and behavior of computer processors and associated devices, as separate from the details of any particular hardware implementation.
The importance of the System /360 cannot be understated: it was a widely successful project that transformed the face of business computing and reshaped the landscape of the computer companies throughout the world. Among many important contributions to the design of the System/360, Brooks was particularly proud of the 8-bit byte, which permitted the use of uppercase and lowercase alphabets and expanded the role of computers in text processing.
While the hardware architecture for the System/360 was well underway, it was clear that there was considerable risk in delivering the operating system for the new series of machines. Brooks was assigned to lead the software team in building what was perhaps the largest operating system project of its time. Brooks describes the lessons he learned in his classic text on software engineering, The Mythical Man-Month. It is from that experience that Brooks proposed “Brook’s Law”: that “adding manpower to a late software project makes it later."
[1] For another example of how wildly views have changed, I recall that early networking assumed that if you were admin on ANY MACHINE on the network, you had admin rights on this machine. There was almost no notion of network security.
My understanding is that before System/360, software was tied to particular machines, which were naturally of a particular speed and capacity (and such resources were a very big deal back then).
When institutions bought new machines, they would MANUALLY REWRITE their software in the assembly language of the new machine. In other words, they were like manual compilers.
I think a lot of the compilers were actually specific to the machine as well! The hardware manufacturers invented their own programming language for their own machines. Portability wasn't a "thing". Many institutions probably only owned a 1 or 3 computers from the same manufacturer anyway.
So basically System/360 was a single instruction set for a lot of different machines, with differing speed and capacity. So you didn't have to do this thing that seems crazy to us today -- you could run the same software on may machines.
Software back then was really just an extension of hardware... The views have changed a lot [1]
Also from what I'm reading, the notion of an "abstract" machine was also not really a thing. There's a conceptual leap from a physical machine on your department's floor to some binary interface you can program against abstractly (the ISA), which we take for granted today.
https://amturing.acm.org/award_winners/brooks_1002187.cfm
Bob Evans promoted IBM’s vision to develop a single product line of general purpose computers with a common instruction set that permitted customers to preserve their investment in software as the moved from slower machines to faster ones. Evans assigned Brooks to lead the team to design this product line, called the System/360, which was announced in 1964. Brooks coined the term “computer architecture” to mean the structure and behavior of computer processors and associated devices, as separate from the details of any particular hardware implementation.
The importance of the System /360 cannot be understated: it was a widely successful project that transformed the face of business computing and reshaped the landscape of the computer companies throughout the world. Among many important contributions to the design of the System/360, Brooks was particularly proud of the 8-bit byte, which permitted the use of uppercase and lowercase alphabets and expanded the role of computers in text processing.
While the hardware architecture for the System/360 was well underway, it was clear that there was considerable risk in delivering the operating system for the new series of machines. Brooks was assigned to lead the software team in building what was perhaps the largest operating system project of its time. Brooks describes the lessons he learned in his classic text on software engineering, The Mythical Man-Month. It is from that experience that Brooks proposed “Brook’s Law”: that “adding manpower to a late software project makes it later."
[1] For another example of how wildly views have changed, I recall that early networking assumed that if you were admin on ANY MACHINE on the network, you had admin rights on this machine. There was almost no notion of network security.
notion of an "abstract" machine was also not really a thing
That's really bizarre to me. We've had the Church-Turing Thesis since the 1930s [1]. I would've thought it ought to have occurred to computer designers from the very beginning that they were following an abstract model of computation. Perhaps they were building bespoke programming languages for their computers in order to achieve lock-in?
[1] https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis
That's really bizarre to me. We've had the Church-Turing Thesis since the 1930s [1]. I would've thought it ought to have occurred to computer designers from the very beginning that they were following an abstract model of computation. Perhaps they were building bespoke programming languages for their computers in order to achieve lock-in?
[1] https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis
”I would've thought it ought to have occurred to computer designers from the very beginning that they were following an abstract model of computation”
They were building bespoke instruction sets because nobody knew what a good instruction set looked like. The size of a byte wasn’t even settled upon yet (also, hardware changed significantly all the time, changing what the best instruction set looked like. If RAM gets ten times faster tomorrow, for example, CPUs might drop a few cache levels)
There also was the fairly significant pressure of stuffing whatever you built in a few kilobytes.
For example, the smallest 360 (https://en.wikipedia.org/wiki/IBM_System/360_Model_20) ran with 4 kilobytes of RAM (and for a measly $2000 a month, you got a card reader/writer/sorter and a line printer with it)
They were building bespoke instruction sets because nobody knew what a good instruction set looked like. The size of a byte wasn’t even settled upon yet (also, hardware changed significantly all the time, changing what the best instruction set looked like. If RAM gets ten times faster tomorrow, for example, CPUs might drop a few cache levels)
There also was the fairly significant pressure of stuffing whatever you built in a few kilobytes.
For example, the smallest 360 (https://en.wikipedia.org/wiki/IBM_System/360_Model_20) ran with 4 kilobytes of RAM (and for a measly $2000 a month, you got a card reader/writer/sorter and a line printer with it)
Thanks I was familiar with the historical importance of IBM's System/360 but what is connection between System/360 and RISC-V? That was what I didn't understand in the OP's comment.
The "360" in System/360 meant "General Purpose" or "Scalable". That is, you could get it in many different sizes and expect that you could buy a bigger one in the future that is compatible with your old programs.
Contrast that to DEC, which had a PDP-8 that was comparable to the smallest 360 but cost about 1/5 as much. If you needed something better you needed to upgrade to the PDP-10 or PDP-11, neither of which was compatible with your PDP-8 programs. PDP-11 was wildly popular but it had no path to 32-bit, so DEC introduced the VAX architecture... Each need to go to an incompatible system was a chance to switch vendors, and that could be one reason IBM is still here and DEC isn't.
Today the x86, POWER, and ARM architectures have all had long rides of continuous improvement, so the scalability ideas of the 360 are mainstream.
RISC-V takes scalability to the next level, targeting various "backwater" areas such as storage controllers. Now that we have SSD's the processors in storage controllers can't keep up with the math to do RAID. Intel's "Rapid Storage Technology" doesn't seem like a scam anymore because there is so much excess power in the Intel architecture compared to the junk that is in contemporary storage controllers.
RISC-V could create a huge market for chips that are scaled down in the ways they need to be scaled down, but scaled up in the ways they need to be scaled up. For instance that storage controller might need to be wicked fast, but it doesn't need floating point and it doesn't need virtual memory. RISC-V lets you pick and choose features but still stick with the some toolset for building code; thus you could port some software between chips with different capabilities.
Contrast that to DEC, which had a PDP-8 that was comparable to the smallest 360 but cost about 1/5 as much. If you needed something better you needed to upgrade to the PDP-10 or PDP-11, neither of which was compatible with your PDP-8 programs. PDP-11 was wildly popular but it had no path to 32-bit, so DEC introduced the VAX architecture... Each need to go to an incompatible system was a chance to switch vendors, and that could be one reason IBM is still here and DEC isn't.
Today the x86, POWER, and ARM architectures have all had long rides of continuous improvement, so the scalability ideas of the 360 are mainstream.
RISC-V takes scalability to the next level, targeting various "backwater" areas such as storage controllers. Now that we have SSD's the processors in storage controllers can't keep up with the math to do RAID. Intel's "Rapid Storage Technology" doesn't seem like a scam anymore because there is so much excess power in the Intel architecture compared to the junk that is in contemporary storage controllers.
RISC-V could create a huge market for chips that are scaled down in the ways they need to be scaled down, but scaled up in the ways they need to be scaled up. For instance that storage controller might need to be wicked fast, but it doesn't need floating point and it doesn't need virtual memory. RISC-V lets you pick and choose features but still stick with the some toolset for building code; thus you could port some software between chips with different capabilities.
Thanks for the detailed response. That makes sense - the idea of "modularity" is certainly a design goal of RISC-v. I was curious about this however:
>"Now that we have SSD's the processors in storage controllers can't keep up with the math"
I haven't looked at hardware RAID boxes in quite some time. I guess I was kind of surprised that this would be an issue. Isn't the math involved just computing the parity of each stripe? Am I overlooking something obvious?
>"Now that we have SSD's the processors in storage controllers can't keep up with the math"
I haven't looked at hardware RAID boxes in quite some time. I guess I was kind of surprised that this would be an issue. Isn't the math involved just computing the parity of each stripe? Am I overlooking something obvious?
In what ways is RISC-V set up to do that better than e.g. ARM? Just the free ISA meaning different companies can specialize better on different segments, or are there novel technical design choices that enable that?
Mainly the free ISA.
The RISC-V ISA does not have new and deep ideas in it (like the Mill) but because it is utterly conventional it is able to build on experience and do a number of little things right that help with performance, power, area, simplicity, etc.
The RISC-V ISA does not have new and deep ideas in it (like the Mill) but because it is utterly conventional it is able to build on experience and do a number of little things right that help with performance, power, area, simplicity, etc.
Exciting writeup! Looking forward to reading this later.