Rust on Propeller 2... we'll need LLVM for that...
DavidZemon
Posts: 2,973
in Propeller 2
We've been investigating Rust at my office over the last couple months and we REALLY like it. It is an astonishingly good language, providing all the speed of C and C++ with the memory safety and high-level feature set of Java and C#.
It's a change from C++, without a doubt, but a manageable one for sure. Here's my reasons why:
* For new learners, it's not any harder to learn than C or C++
* For young people (I'm thinking about brain flexibility here, so draw the line wherever you want) with little programming experience, learning a new language isn't a big deal
* For experienced programmers with years of C/C++ knowledge: you know why we need a new language. Just look at Heartbleed if you need a reminder. Or Microsoft claiming that 70% of all its patches are memory management related.
So who's left out from the above list? Off the top of my head, I'm thinking about the casual hobbyist that just wants to turn an LED on whenever his garage door is open. She's not interested in learning a new language - she just finished a similar project for her dishwasher. For her, learning Rust probably isn't worth it. And maybe that's a big part of this community... I don't know. For her, the difference between LLVM and GCC doesn't make a lick of difference, other than GCC will be easier because we already have community members that know how to do it.
But I am now firmly on the side of wanting LLVM rather than GCC.
And yea, I know Peter, there's no memory management in Forth either
It's a change from C++, without a doubt, but a manageable one for sure. Here's my reasons why:
* For new learners, it's not any harder to learn than C or C++
* For young people (I'm thinking about brain flexibility here, so draw the line wherever you want) with little programming experience, learning a new language isn't a big deal
* For experienced programmers with years of C/C++ knowledge: you know why we need a new language. Just look at Heartbleed if you need a reminder. Or Microsoft claiming that 70% of all its patches are memory management related.
So who's left out from the above list? Off the top of my head, I'm thinking about the casual hobbyist that just wants to turn an LED on whenever his garage door is open. She's not interested in learning a new language - she just finished a similar project for her dishwasher. For her, learning Rust probably isn't worth it. And maybe that's a big part of this community... I don't know. For her, the difference between LLVM and GCC doesn't make a lick of difference, other than GCC will be easier because we already have community members that know how to do it.
But I am now firmly on the side of wanting LLVM rather than GCC.
And yea, I know Peter, there's no memory management in Forth either
Comments
Eh, it really mostly is just changing the commands from "gcc" to "clang", the command-line interface is basically identical between the two. CLang also supports most (all?) nonstandard extensions that GCC does (labels-as-values, __attribute__, _builtin_popcount, etc.)
Agreed. This played into my thought process as well. If P1 had a complete and modern GCC port ready to go already, and it was just a matter of updating for P2 instructions, that'd be one thing. But given the state of things, LLVM seems like not that much bigger of a jump with significant benefits on multiple fronts.
You can compile binaries with given start addresses and 'link' them together with the 'file' directive. That is the way I combine the TAQOZ binary with a compiled fastspin program.
Mike
I think the p2gcc assembler and linker could be a good starting point, but they need to be fleshed out and made to support all the relocations needed for P2 instructions, and ideally have some debugging information added in as well. Or, we could port GNU binutils. Or perhaps the LLVM equivalents.
And learning any computer language is a big deal thank you very much! There is so many details about syntax/version/extension, CPU/memory architecture, OS/filesytem architecture, library/hardware utilisation, compile/build/package handling.
I fixed your post for you
I don't have time right now to try this, but I'd be happy to help anyone out who does want to give it a whirl.
Rust is certainly a hyped language these days. It still uses the ugly C syntax instead of an easy-to-read pseudo-code-like Algol syntax, as used by languages such as Pascal, Modula, Oberon, Ada, Dylan. The latter recently got an LLVM front-end. However, I still see Ada as an underrated language, rarely even mentioned, despite having been around for a long time, having been designed for the programming of embedded systems and having been part of GCC for decades. Here is a nice overview of its features: http://cowlark.com/2014-04-27-ada/index.html
Ada looks like a much better teaching language than Rust. There might even be opportunities to partner with Adacore, which currently maintains the most popular Ada compiler implementation, to get support for the P2 and to create educational resources (they have in the past supported Ada development for Lego Mindstorms for educational purposes). Doesn't SPIN also use an Algol syntax? I think, Ada improves on the original notation.
I disagree about the ugliness. This entirely a matter of opinion, and as much as I like long variable names and and descriptive function names, "begin" and "end" are completely unnecessary when curly braces will do just fine. Me and everyone else at my company are quite happy with the C-family syntax. Everyone that knows C, C++, Java, and C# will be happy with the C-family syntax.... and that is a BIG percentage of the world's programmers.
Right, i don't imagine Rust will ever be good for teaching young children. It's not meant for that. There are far too many rules that will seem arbitrary and annoying probably. That doesn't negate the need for a language like Rust though, that enforces safe practices by default (like all variables being immutable, unless you explicitly declare them mutable).
And as it happens for myself I have a stranger then fiction attachment to APL. Back in the day, there was a story that one of the IBM S/370 systems was strapped to think in APL, and as a lower level language BAL (Basic Assembler Language) . In fact APL was written to make building them easier, or so it seemed.
And naturally what I was thinking of, is a P2 who normally worked in Spin2 and probably PASM2, but also in APL/p2. But bear with me, a serial port would be directed to a teletypewriter of the Selectric sort. (But with an APL typeamatic.)
It would be an interesting scene at the Vintage Computer Fair, or even Maker Faire when they get reconstituted.
---
Mascot away until Monday.
LLVM uses its own linker, LLD, instead of Binutils, although it uses the same syntax as LD, and if I recall correctly, it is a drop-in replacement.
The cleaner code base is probably not the largest advantage of an LLVM compile path, over GCC. It's probably compartmentalization; they've simplified the entire process of creating a new target into the creation of a relitively small number of files unique to that target, without modifying existing files.
To create a P2 target for Clang, you don't have to touch the C compiler; you only have to define the layout and access methods to registers and RAM. Clang (along with compilers from other languages) will use that to compile to a pseudo-assembly-language file that is structurally compatible with the target. The code generator will take the pseudo-assembly-language file and use a few more target-specific files, to convert the pseudo assembly language into target-specific assembly language.
Here's the AVR implimentation: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/AVR/. It only has about 100 files. A similar target for the P2 could be distributed separately from LLVM and Clang, and users could upgrade the compiler system, but keep using the same P2 target files.
Cool, you started looking at Rust about the same time I did. I was sold on it as soon as I found I could create code that ran as fast as C. My first Rust programs were translations of existing C, as such they are probably very poor Rust style but it showed how easily that could be done. In some cases the resulting code was even a bit faster than the original C.
You remember my old FFT for the Propeller? And the resulting fft_bench that compared doing that FFT in all kid of languages: https://github.com/ZiCog/fftbench, There is now a Rust version in there.
As for beginners, the first high level language I learned for production use was C (After BASIC at tech school and tinkering with ALGOL at uni). All I had was a PC and the Microsoft C compiler and manuals. With no mentors around the going was slow. Took me while to realize that this was a high level language but it could crash and burn as obscurely as assembler program! After which debugging it was a pain. It would have be so much easier to start with Rust.
Back in the day, when there was no C compiler for the Propeller I created Zog. The ZPU interpreter for the Prop. Which in turn could be used to run C programs compiled with zpu-gcc.
That suggests a couple of possibilities to get Rust running on the P2....
1) WASM https://webassembly.org/
WASM is the new byte code for the web. Rust and many other languages can be compiled to WASM already. It had crossed my mind it would be an excellent way to deliver software updates to remote micro-controller projects if performance is not crucial. A minimal WASM interpreter is only a couple of thousand lines of C: https://github.com/kanaka/wac
2) RISC V
How about a RISC V emulation for the P2? With such a small instruction set that must be a breeze.
All of a sudden I feel a Propeller 2 project coming on.... now where do I actually get one from?
Peter has alternate more compact board - https://forums.parallax.com/discussion/170695/p2d2-with-p2-revb-taking-orders/p1
Eric already has RiscV emulation done - https://forums.parallax.com/discussion/comment/1475881/#Comment_1475881
Eric will comment, but from what I understand it is a JIT RISC V compiler.
Oh, and you really need to look at these P2 instructions...
execf, skip skipf, and friends
That sounds amazing.
Sadly I don't think I will have the time or mental capacity to get into P2 assembler any time soon. I was thinking in terms of writing a RISC V or WASM interpreter in C.
Hi Heater, welcome back! I've ported an older version of your fft_bench to the various C compilers for the P2, with the following results (all are with an 80 MHz clock, which is ridiculously slow but allows easy comparison to P1):
The command lines used were:
https://github.com/totalspectrum/riscvp2
is a JIT compiler for an rv32imac instruction set (although the atomic "a" instructions are probably not completely correct yet). The repository contains instructions for turning a RISC-V gcc into a P2 gcc. It works by setting up a custom linker script which links the JIT compiler at the very beginning of the executable (to run at 0) and the RISC-V code after that; the P2 boots up into the JIT system which then starts running RISC-V instructions. Something similar should be possible for Rust.
There are custom RISC-V instructions for many of the P2 features (like smartpins). Performance is pretty good, as you can see by the fft-bench results above.
Mike