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 ;)
David
PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
CI Server: https://ci.zemon.name?guest=1

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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • 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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • 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.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • 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 ;)
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • 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
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
Sign In or Register to comment.