Announcement

Collapse
No announcement yet.

LLVM 10.0-RC3 Released With The Final Expected Soon For This Big Compiler Update

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Brane215 View Post

    I think it could generate PIC32 - MIPS32BE code.
    It's not PIC8, but for that, there already are good enough solutions.

    I'm not great Rust advocate, but they seem to be onto something. And those extra compile-time security checks with zero runtime cost are EXACTLY what doctor ordered for microcontroller work. So, all I am saying, you might want look into that.
    If my original wish in this thread comes true, then I would be able to use Rust for my PIC8 stuff as well

    Comment


    • #12
      They can't have ABI stability while language is still evolving. You can0t fix something which is not yet clear how should look to fill the current needs and have reasonable lifetime expectancy.

      Same with the libraries.
      Rust is using C's lean&mean approach. Which means that they have to measure and crowd-test the impact of every decision and change to see what it actually does in real life.

      You can't have it all at once, fresh and new language with underlying subsystem AND stability AND feature set.

      For a tool that is still evolving, it looks pretty darn good IMO.
      Whole friggin OS was done with it.

      It certainly looks like it can handle a microcontroller.





      Comment


      • #13
        Originally posted by orangemanbad

        If you read the various issue threads and core developer blog posts on the subject of ABI stability and put 2 and 2 together, it becomes very obvious that they're never going to have it.

        You should try to do more programming and less navel gazing.
        Enlighten me, please.
        Why exactly will they never have ABI stability ?
        And if so, why would it eb essential part of simple microcontroller work ?

        BTW: what do you mean under "ABI stability" ?
        Standardised library set, calling conventions or something else ?

        Comment


        • #14
          Originally posted by orangemanbad
          It's a well defined concept. Try Google..
          People tend to use their personal flavor of it. I just wondered about yours.

          The way the Linux syscall interface works would be impossible without it.
          Why. Linux uses SYSCALL/SYSRET or similar instruction pair. WIth particular register content on entry and return. And probably a few _asm_ sections on kernel as well as glibc side par packing/unpacking and checkign parameters. So what ? I mean, which of these are unattainable in Rust ? At worst, you'd have _asm_ section in system_call(whatever).

          IIRC RedOX was done entirely in Rust as a proof of the principle.


          Dynamic libs would be much less useful in distros without it.
          I don't see why. Rust already works with any C/C++/ etc libs that. I don't remember ever seeing the requirement that GTK has to be recompiled as a static lib to be used with rust etc. I don't know about Rust lib that is to be dl-oaded in C/C++ runtime though. I suspect there currently might be a snag but that it is working.

          Even if some of those compatibility points would be shed at some futrure point ( which I doubt, since Rust is looking to take over part of the C/C++ programming base), I wouldn't care too much. Whole point of Rust is starting with a clean slate.

          Yes, borrow checker is PITA2, but there is good reason for that. Pattern matching and auto-typing simply rocks. I've seen nothing comparable in language so lean&mean.
          And there are plenty of others. Whole tmplate business in C++ was meant well, but turned out to be a catastrophe. Rust has taken the lessons from that and made new effort, which looks darn good to me. Packaging Cargo along the language also seems to give it whole platform to live in.
          I like it. Not that I0ve done much work on it other that exploring and learning, but so far, I like what I see.

          I can totally see its value within some open source multitarget microcontroller IDE with Rust as either only or one of the main venuew, along with ASM/C/C++.

          Comment


          • #15
            Originally posted by orangemanbad

            Please spare me the technobabble, in an attempt to establish your big swinging dick credentials.
            I have no "swinging dick credentials". I am just an inquisitive asshole ;o)

            Comment


            • #16
              Originally posted by orangemanbad

              Redox is a toy that hasn't had to face the real world. Part of why Linux was successful is the "we don't break userspace" policy (which includes the ABI). It's easy to produce software when you just punt on all the details that make it practical in the real world and tell people "you don't need that".
              Redox value is as proof of concept and demonstration of Rust reach, more than an actual tool.


              I've used Rust long enough to like the langauge a lot. But I don't like the toolchain at all, nor the direction it's headed. I want something to replace C, especially in a Linux distro context, and Rust is simply unsuitable for the task...
              Methinks we'll be seeing it more and more in open source stuff. Wouldn0t be surprised to see GTK switch to it one day and many others, too.
              Not today, but some day...

              Comment

              Working...
              X