kc5tja
(Samuel A. Falvo II (Please Delete my Account))
1
I hope this post is acceptable use of the forum. I’ve been invited to join these forums, and thought I’d say hello. My name is Samuel A. Falvo II, and I’m the founder, maintainer, and developer of the Kestrel Computer Project. I work with RISC-V technology on a hobby basis at present, and hope someday to find my niche in the open-hardware / open-source hardware movement.
Current RISC-V activities include working on Polaris, the hardware reiification of the Kestrel-3 emulator’s virtual CPU. The result will sport a 64-bit datapath, hopefully run at 6 MIPS performance (average), and yet still be small enough to fit in an iCE40HX-4K FPGA. It’s M-mode only (no S/U-modes!), no memory protection features, and pretty much just a stock, uninteresting CPU otherwise. I often compare it to a 64-bit Z-80 or 6502.
It’s written by hand in Verilog and my own productivity tool called SMG (State Machine Generator, a misnomer, but don’t know what else to call it). Preliminary synthesis and timing analysis using Yosys suggests an iCE40HX-4K ought to be able to support up to a 28 to 32MHz clock, giving it a performance somewhere in the vicinity of 7 to 8 MIPS. Hopefully, the design will still meet its performance goal when I’m finished; I haven’t checked in a while.
I’m most active on Twitter (@SamuelAFalvoII; warning: this is a personal account, and I often gripe about day to day stuff. I also retweet a lot of things, often involving cats on the Internet. If you don’t want to follow me because of excessive traffic, I understand completely!) and on Hackaday.io.
Hello, I’m Erich, proud owner of a HiFive1
I’m a Forth person, contributor to the amforth.sf.net project. So naturally I would like to see Forth run on the E310.
Hello Samuel,
I have seen your blog entries on http://sam-falvo.github.io/kestrel/ regarding Forth on risc-v. So I’m wondering: is Forth unfeasible? Do you have code worth trying to port to the E310? Or other suggestions?
Should this thread be moved to another section?
Cheers,
Erich
kc5tja
(Samuel A. Falvo II (Please Delete my Account))
5
Hello; I responded to your query via e-mail. Maybe if the question were moved to a new location in the forum, I can cut/paste my response there and clean up the formatting.
Forth is perfectly feasible on RISC-V. As with most other RISC architectures the typical simplistic Forth implementation from 1970s machines won’t make good use of a RISC – it won’t use many of the registers, and direct translation to machine code will be bulky because RISCs don’t usually have indirect or auto-increment addressing.
A slightly more sophisticated “compile” word could make pretty good code from Forth by simply keeping track of operand stack offsets within the word being defined and access them like 8(sp), 40(sp) etc and only adjust the stack pointer at the start and end of the function.
However there is a bigger problem specifically with HIFive1, which is that there is 16384 KB of flash memory for storing downloaded programs in, but only 16 KB of RAM for code and data entered interactively. So you’d want to compile as much as possible in advance, on a host computer, load it into flash, and maybe use a compact form such as token-threading in RAM.
kc5tja
(Samuel A. Falvo II (Please Delete my Account))
7
16K RAM isn’t nearly as big a problem as many make it out to be, provided you have a fast enough compiler.
I’ve already replied via e-mail on this topic; the blog articles he’s referring to focus on my attempts at getting Machine Forth to compile efficiently to the RISC-V architecture. The conclusion is that ITC, DTC, or STC is better suited (at least with a simplistic compiler).
Efficiency doesn’t depend on # of registers used, but on total execution time. If you can get by with only a small handful of registers but still run fast, then that’s a win. Remember, one Forth word is roughly equivalent to 1.5 to 2 lines of code in C, so don’t expect large register usage. At any given time, it’s recommended that you deal with, at most, 3 items on the stack at once. Anything more than that will overload your brain. So register usage is going to be small anyway.
kc5tja
(Samuel A. Falvo II (Please Delete my Account))
8
Since I mentioned Kestrel Project in this post, I thought I’d follow up.
Sorry to hear that! You were an active and enthusiastic voice and will be missed. Best of luck in your next endeavor and you’re always welcome back any time!
The Kestrel Project looks like a good idea, kc5tja. Thanks for working on it.
Are you familiar with the Talos Project? It tried crowd funding support for a POWER8 Libre system.
Hi, brucehoult. It is great to have somebody like you in a technical forum like this. You have the rare quality of sounding both knowledgable and easy to understand!
kc5tja
(Samuel A. Falvo II (Please Delete my Account))
15
Thanks! I think it very definitely fills a need, even if I am taking a deliberately difficult approach towards designing it.
I am aware of the Talos project. Both Talos and Kestrel projects share a fundamental understanding of the security and peace of mind issues surrounding the need for open computers. However, that’s where our similarities end. We have very deep philosophical differences about how to approach the open-source computer market. I wanted to be wrong, but I do feel vindicated that the Talos project basically died on the vine for reasons of community and expectations mismanagement. Here’s where I think Raptor went wrong:
Raptor was using a computer architecture best described as a mid-sized, commercial mainframe – think something on par with AS/400 but without the cool OS to go with it. Besides its 12 or 16 processing cores, it was built for insane quantities of I/O and memory bandwidth. But, with great power and performance comes greater responsibility: in this case, the need to administer a system of this capacity. As I point out later, they looked to Linux (demonstrably a mainframe-class OS) to make this system usable.
Raptor’s outreach never really connected with an audience of appreciable size. Lots of bullet points, lots of impressive specs, but the price point was well outside of any reasonable home user, and even most commercial users too. This was a machine designed by mainframe or supercomputer enthusiasts, for said enthusiasts. A bare motherboard would have cost $4000, and a populated board upwards of $7600 (based on memory of their Kickstarter page). That’s unrealistic: the price/performance ratios for 2 or 3 Intel machines are vastly superior to the single Talos board.
Raptor Engineering was deeply dismissive of its competition. Paraphrasing too many blog posts and tweets, the message over and over was always one of, “This will never succeed,” “that will never work,” and “only we have the right solution.” Though my project was not explicitly named in their blog articles or ad copy, a lot of what was said can be interpreted to reference my project, as well as many others on the Internet. He mentioned RISC-V on a plurality of occasions as an untenable processor architecture for the open computing world’s needs. Maybe it is? Who knows; but in his negativity, he rarely focused on actual benefits of his platform and why $4000 was a justified price for a bare motherboard. This kind of negativity has no place in an open community, and I think people recognized that.
Raptor Engineering focused too heavily on hardware, leaving it to the Linux community to support the platform. This is a great division of responsibility; however, it’s also fraught with peril too. For instance, imagine releasing the computer, only to find out sales are sluggish to non-existent. The probability of running mainstream Linux distributions on your hardware drops to zero, despite being a computer that otherwise aims to be completely open and in FSF’s direct interest.
Here’s how I think I do things differently:
While I, too, am inspired by mainframes, I’m carefully trying to balance inspired architectures with a priority on home usability. I look to four inspirations right now: System/360, Atari 400/800, Commodore PET, and Commodore-Amiga. Note the S/360 is the only “commercial” computer on the list. Note that the other three did not require any significant effort to administer. When people come home from an IT job, the last thing they want to do is do IT at home too. Admin-free computing is a unique selling point these days.
My outreach to the public is based on humility. The first editions of the Kestrel design are based on the idea of keeping things as simple as I can reasonably make things, and incrementally improving things over time. Unlike Raptor, I am willing to sacrifice performance for simplicity. (I rant and I rave when I have to do it, but my values are more important than my vanity.) People who are interested in the Kestrel seek it out for this reason first and foremost, at least I think. The market is already saturated with complex hardware solutions that already work (for some definition thereof); there’s no reason to compete with them. At least, not yet.
I have never dismissed Raptor Engineering then, and I do not intend to start now. They’re smart. They’ve got resources. They know their audience. It just isn’t as big as they’d hoped, and there’s nothing wrong with that. I did want to see Talos fly, for I love PowerPC as much as I love RISC-V. However, Talos is gone, and Kestrel is still here. And while my fan base isn’t nearly as rich or as large as Talos’, they’re still here with me. And that’s all that matters.
I have a keen interest in “co-engineering” the Kestrel: designing the computer holistically with hardware built for the benefit of system software, and vice-versa. This is what makes the System/360 family of mainframes and the Commodore-Amiga family of home computers unique. Besides a rare opportunity in the industry to truly try and reduce the complexity behind how a computer is built and/or works, it also guarantees I’ll have an OS for it at all times. While I don’t aim to forbid Linux from running on the Kestrel long-term, I do feel that having a purpose-built OS for the platform, particularly something that a single person could easily port to a new Kestrel design, is a necessary first-step, even if overall usage is low. I challenge any single person to port a viable Linux OS to a new processor architecture in a single fiscal quarter.
Anyway, I hope this illustrates why I steadfastly stick to my guns with the Kestrel as it’s currently designed instead of adopting a more Talosian approach. And maybe Raptor is right in that RISC-V is not a viable CPU architecture to compete with Intel today; who cares? People want the openness of the architecture. I’ve personally witnessed Sifive running Quake quite well on a 62MHz CPU over a bodged and horrifically inefficiently utilized PCIe interconnect. It was vastly more than adequate for day to day computing tasks, and in the end, that’s what people really care about.
