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

  • Brane215
    replied
    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...

    Leave a comment:


  • Brane215
    replied
    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)

    Leave a comment:


  • Brane215
    replied
    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++.

    Leave a comment:


  • Brane215
    replied
    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 ?

    Leave a comment:


  • Brane215
    replied
    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.





    Leave a comment:


  • Raka555
    replied
    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

    Leave a comment:


  • Brane215
    replied
    Originally posted by orangemanbad

    Language advocacy in 2020... The cringe is too strong.
    Relax. It was just half question/half a suggestion.

    Rust is not just another syntactic tool. It brings quite a few new things to the table. Most of them sorely needed in microcontroller world,
    esepecially nowadays that IoT is getting pushed into a toiet paper.

    Leave a comment:


  • Brane215
    replied
    Originally posted by Raka555 View Post

    JAL generates PIC code. Can Rust ?
    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.

    Leave a comment:


  • Raka555
    replied
    Originally posted by Brane215 View Post

    OK, but it seems that benefits don't come close to covering the costs, so probably no one will do it.
    PIC12/16 cores are VERY quirky. They aren't even remotely similar to AVR etc.
    So, while compilers for them do exist, I doubt that quality of generated code is very good.

    LLVM is optimized toward being greatest with modern, 32-bit and 64-bit cores. NO one really cares outside of that world.

    WRT to JAL - why not Rust ? It offers additional safety checks with essentially zero run overhead, it's nice and simple and is being evolved toward microcontrollers these days.
    And, it is based on llvm. It is dfeveloped at prety brisk tempo these days...
    JAL generates PIC code. Can Rust ?

    Leave a comment:


  • Brane215
    replied
    Originally posted by Raka555 View Post
    I do use the Microchip compiler.
    I also use Jallib : http://justanotherlanguage.org/

    It would have been great to target PIC8 with the compiler I am working on, which uses an llvm backend. Hence my interest.
    OK, but it seems that benefits don't come close to covering the costs, so probably no one will do it.
    PIC12/16 cores are VERY quirky. They aren't even remotely similar to AVR etc.
    So, while compilers for them do exist, I doubt that quality of generated code is very good.

    LLVM is optimized toward being greatest with modern, 32-bit and 64-bit cores. NO one really cares outside of that world.

    WRT to JAL - why not Rust ? It offers additional safety checks with essentially zero run overhead, it's nice and simple and is being evolved toward microcontrollers these days.
    And, it is based on llvm. It is dfeveloped at prety brisk tempo these days...

    Leave a comment:

Working...
X