Rust on Propeller 2... we'll need LLVM for that...

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 ;)

Comments

  • DavidZemon wrote: »
    other than GCC will be easier because we already have community members that know how to do it.

    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.)
  • Wuerfel_21 wrote: »
    DavidZemon wrote: »
    other than GCC will be easier because we already have community members that know how to do it.

    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.)
    It would certainly be interesting to come up to speed on LLVM as it seems like a cleaner code base. However, I think the learning curve might be pretty steep. Also, even if we go with GCC, we will want to use the latest version and there will be some work involved in moving the P1 GCC code to the latest release of GCC.

  • David Betz wrote: »
    Also, even if we go with GCC, we will want to use the latest version and there will be some work involved in moving the P1 GCC code to the latest release of GCC.

    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.
  • DavidZemon wrote: »
    David Betz wrote: »
    Also, even if we go with GCC, we will want to use the latest version and there will be some work involved in moving the P1 GCC code to the latest release of GCC.

    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.
    Well, if you want me to get involved in GCC or LLVM then there is a bigger learning curve for LLVM for me. I've done work inside GCC but haven't looked very closely at LLVM yet. I know Eric has more experience than I have with GCC. I don't know how much he's looked at LLVM. Are there other forum members who know LLVM who want to get involved?

  • Porting the compiler is only part of the puzzle. We also need an assembler, linker, and archiver (preferably all of binutils). Porting those to P2 is necessary and non-trivial (not impossible by any means, but not to be underestimated either). Indeed just updating GCC to output P2 instructions would be simple, but it wouldn't do much good without also updating binutils to handle the P2, and that's a much bigger job.
  • ersmith wrote: »
    Porting the compiler is only part of the puzzle. We also need an assembler, linker, and archiver (preferably all of binutils). Porting those to P2 is necessary and non-trivial (not impossible by any means, but not to be underestimated either). Indeed just updating GCC to output P2 instructions would be simple, but it wouldn't do much good without also updating binutils to handle the P2, and that's a much bigger job.
    Well, there was a theory a while back that we could bypass binutils and use one of the existing P2 assemblers. Not sure what we'd do about linking though. I don't think we have a P2 linker yet do we?
  • sort of a linker.

    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.
    DAT
    	ORGH	0
    	ORG	0
    	file 	"TQ_TAQOZ.BIN" 
    	ORGH	$10004 			' $10000 is Mailbox between TAQOZ and Rest of Program
    	ORG	0
    	file 	"TQ_Link.binary"
    

    Mike
  • The FILE hack is definitely not a linker in any meaningful sense (it will not help us with getting GCC to work). p2gcc does come with a linker of sorts, but I think it's missing a lot of things that GCC and the libraries expect. I guess it all comes down to what people want -- do they want a full development system for P2 with all features, or a collection of hacks that sort of works a lot of the time? If it's the latter then we already have several C compilers that people could work to improve.

    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.
  • ersmith wrote: »
    The FILE hack is definitely not a linker in any meaningful sense (it will not help us with getting GCC to work). p2gcc does come with a linker of sorts, but I think it's missing a lot of things that GCC and the libraries expect. I guess it all comes down to what people want -- do they want a full development system for P2 with all features, or a collection of hacks that sort of works a lot of the time? If it's the latter then we already have several C compilers that people could work to improve.

    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.
    Doesn't LLVM use binutils as well? I thought it just replaced the compiler part of GCC.

  • Lol, Rust better be easier to learn than C++. C is already a tough but useful one, C++ is just ridiculous.

    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.
  • evanh wrote: »
    Lol, Rust better be easier to learn than C++. C is already a tough but useful one, C++ is just ridiculous.

    And learning mastering 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 ;)
  • The quickest way to get Rust on Propeller 2 is probably to follow the directions for getting it working on Risc-V https://softsourceconsulting.github.io/rst/from-zero-to-rust-on-riscv.html. Then merge in the riscvp2 changes. There are probably a few things you'll have to change along the way, but glancing through the instructions I don't see any show stoppers, You'll have to change some paths in the riscvp2 Makefile for where to install the emulation code and linker scripts, and you'll have to adapt the directions in the "zero to rust" script to connect to a P2 instead of HiFive board.

    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.
  • That's a good idea. I bring my P2ES to the office and give it a whirl when I get a chance
  • DavidZemon wrote: »
    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.

    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.
  • 12345 wrote: »
    Rust... still uses the ugly C syntax instead of an easy-to-read pseudo-code-like Algol syntax...

    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.
    12345 wrote: »
    Ada looks like a much better teaching language than Rust.

    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).
  • Yes DZ, Rust certainly is the big thing in the embedded world. And as it happens Forth is still popular in the CDP1802/COSMAC world.

    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.
  • David Betz,

    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.
  • DavidZemon,

    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?
  • evanhevanh Posts: 9,404
    edited 2019-12-26 - 22:42:14
    https://propeller.parallax.com/ for Parallax support, including the shop. Fresh batch of RevB Eval Boards available 6th Jan 2020. RevB chips purchasable in packs of 4 now. RevC will be around April/May.

    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

  • Cool, even better, not just a RISC V emulation but some kind of RISC V to P2 binary translation. If I understand correctly.
  • Heater. wrote: »
    Cool, even better, not just a RISC V emulation but some kind of RISC V to P2 binary translation. If I understand correctly.
    Yes, and it's pretty robust. He used it to port MicroPython to the P2.

  • Cluso99Cluso99 Posts: 16,094
    edited 2019-12-26 - 23:53:05
    Heater. wrote: »
    Cool, even better, not just a RISC V emulation but some kind of RISC V to P2 binary translation. If I understand correctly.

    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
  • Hi Cluso,

    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.

  • ersmithersmith Posts: 4,109
    edited 2019-12-27 - 13:12:44
    Heater. wrote: »
    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.

    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):
    results: time / size of binary loaded to P2
    
    riscvp2:  25245 us  20968 bytes
    fastspin: 39835 us  16384 bytes
    catalina: 55876 us  27808 bytes
    p2gcc:    64765 us  21204 bytes
    

    The command lines used were:
    fastspin -2 -O2 -o fastspin.bin fft_bench.c
    catalina -lci -p2 -O3 -C P2_EVAL -C NATIVE -D PROPELLER fft_bench.c
    p2gcc -D _cnt=getcnt fft_bench.c
    riscv-none-embed-gcc -T riscvp2_lut.ld -specs=nano.specs -Os -o a.elf fft_bench.c
    
    2) RISC V

    How about a RISC V emulation for the P2? With such a small instruction set that must be a breeze.

    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.
  • Hi Heater, I thought you had one of the early eval boards but I can send you one of my test P2D2s as I have some here. I understand your position and having to scrape by so there is no charge, but I might just send it regular airmail so it might take a week or so. Just pm your address. Welcome back!

  • +1

    Mike
Sign In or Register to comment.