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.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."
  • 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
  • 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).
    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
  • 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.
Sign In or Register to comment.