Announcement

Collapse
No announcement yet.

Libre-SOC Test ASIC Going To Fabrication, Using TSMC 180nm Process

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

  • programmerjake
    replied
    Originally posted by lkcl View Post

    i didn't say it was "useless", i said "not a productive use of my time given the priorities and the tasks that are on the critical path right now", which is completely different.
    ah, ok.

    Leave a comment:


  • lkcl
    replied
    Originally posted by programmerjake View Post
    All of those collectively very smart people think Rust is far from useless.
    i didn't say it was "useless", i said "not a productive use of my time given the priorities and the tasks that are on the critical path right now", which is completely different.

    Leave a comment:


  • programmerjake
    replied
    Originally posted by lkcl View Post
    what is the justification? i am not going to learn a language that has no use-case and no purpose, particularly one whose underlying syntax is unreadable as plain english.
    Well, Microsoft thinks Rust should replace C/C++ going forward: https://thenewstack.io/microsoft-rus...s-programming/

    Amazon thinks Rust is awesome:
    https://aws.amazon.com/blogs/opensou...-like-to-help/

    According to Stackoverflow's yearly surveys, Rust programmers love Rust and want to keep using it, it's topped the most loved languages ranking for 5 years (!) in a row:
    https://stackoverflow.blog/2020/06/0...ve-it-so-much/
    All the Rust programmers that I'm aware of in Libre-SOC (Cole and me) think Rust is very useful.

    All of those collectively very smart people think Rust is far from useless.

    Leave a comment:


  • programmerjake
    replied
    Originally posted by lkcl View Post
    it does: you use ABC decorators, inheriting from metaclass ABCMeta, and mark the function that needs to be "traited" with @abstractmethod. any class that then inherits from the base then is *required* to override (have) that method.
    That's waay underselling the power of Rust's traits, they allow abstracting over types, *including* types from other people's code, without needing to modify their types in any way. Python requires modifying the foreign types, causing leaky abstractions. Traits can also be used for tagging a category of types, without needing to add any methods. Traits can be implemented on particular combinations of types, allowing easy multi-type dispatching:

    Code:
    trait MyTrait<T, U> {
        type Output;
        fn my_method(self, t: T, u: U) -> Self::Output;
    }
    
    // impl #1 -- abstracting over built-in and standard library types -- not our types
    impl MyTrait<i32, f64> for String {
        type Output = Vec<bool>;
        fn my_method(self, t: i32, u: f64) -> Vec<bool> {
            todo!("my_method for String, i32, and f64")
        }
    }
    
    // impl #2 abstracting over all types U that implement addition
    impl<U> MyTrait<bool, U> for U
    where
        U: Add<Output = U>
    {
        type Output = String;
        fn my_method(self, t: bool, u: U) -> String {
            let v = self + u; // we can add, v's type is U due to the Output = U
            todo!("my_method for U, bool, and U, for any type U")
        }
    }
    
    fn f() -> Vec<bool> {
        let s = 1.0_f32.my_method(false, 3.5); // call impl #2 with U = f32
        // s is a String
        s.my_method(1, 4.5 + 5.5) // call impl #1
    }
    Originally posted by lkcl View Post
    what is the justification? i am not going to learn a language that has no use-case and no purpose, particularly one whose underlying syntax is unreadable as plain english.
    Imho Rust is pretty readable, if you know C, learning Rust's syntax should be pretty easy, they specifically chose to make the syntax look familiar to C/C++ except where C does a bad job (types -- ever tried to declare an array of function pointers in C? bleh.).

    Originally posted by lkcl View Post
    • the linux kernel is in c. we need to develop linux kernel drivers.
    • u-boot is in c. we need to port u-boot to Libre-SOC.
    • unit tests are written in pure assembler.
    • binutils, which we need, is written in c
    • both gcc and llvm are both written in c++.
    • ffmpeg is written in c++
    • gem5 is in mixed c++ and python
    • cavatools is in mixed c with python-based generator/compiler scripts
    that pretty much takes care of the next 3 years of development of Libre-SOC: at no point in that will rust be *immediately* useful, so why do i need to spend 6 months learning it?
    Well, Kazan, Libre-SOC's Vulkan driver, is written in Rust. Rav1e, the (claimed) *fastest* AV1 encoder is written in Rust. Linux will shortly also be written in Rust. Wasmtime (used by nmigen), is written in Rust.

    Originally posted by lkcl View Post
    each of those dependencies above are multi-DECADE projects and above. any time spent replacing any of those by rewriting them in rust, unnecessarily, become themselves massive multi-DECADE projects, representing a massive distraction and diversion away from the goal that's been set (and funded by NLnet). look at how long GNU/Hurd, one of my favourite alternative kernels, took: they simply couldn't keep up.
    I don't think *rewriting* the world in Rust is necessarily a good goal, rewrites often contain bugs and missing features that the old version didn't have. That said, writing *new* code in Rust is a very good idea in nearly all cases!

    Originally posted by lkcl View Post
    therefore, given the time pressure and the responsibility that we have to honour our obligations to NLnet, any time that i spend learning rust is actually a pretty irresponsible use of my time.

    bottom line is, we have to be really tough and realistic, and leverage what's *avalable*, rather than do what we *like* to do because it's a personal preferred interest.
    Considering at least EUR 25,000 of NLnet's money is going towards writing a Vulkan driver *in Rust*, and because of the list of important-to-Libre-SOC projects that are written at least partially in Rust, and because of the benefits of Rust, I think taking time at some point to learn Rust should be seriously considered.

    Leave a comment:


  • lkcl
    replied
    Originally posted by programmerjake View Post

    That Rust HDL could have all the parts that made BlueSpec so great -- guaranteed synthesizability, strong typing, good type checking, expressive types, etc. Too bad BlueSpec was not an option due to its proprietary nature.
    i've watched people do programming in bluespec, and tried it myself. i worked side-by-side with someone who is a known expert in BSV. we had to stop - twice a day - and spend up to an HOUR trying to desperately and patiently work around the strong typing that BSV forced on us.

    it actually got embarrassing: the person i was working with had so many other people needing his time that i had to sometimes waste an entire day not doing anything at all, because his time spent searching through the documentation for a way round the problem that strong typing created was distracting him from being able to help the rest of the team.

    whilst you might think initially that strong types are "great", and they "save" you from making "mistakes", in reality they're just a damn nuisance.

    consequently, i would expect any rust-based HDL, rather than being useful and productive, to similarly so intensely annoy its users that they give up on it. not only that, but remember we went through this, spending several weeks evaluating existing HDLs. with no pre-existing community, and no base libraries, we'd literally be creating everything from scratch (and then have to maintain it ourselves). that represents - again - an irresponsible use of time, and would place the project in an extremely risky position of having to train developers first in rust, then in rust HDL, and finally in the Libre-SOC HDL.

    Leave a comment:


  • pal666
    replied
    libre-resistive-heater?

    Leave a comment:


  • lkcl
    replied
    Originally posted by programmerjake View Post

    Though imho we're over-using inheritance since python doesn't really have other good abstraction tools such as Rust's traits.
    it does: you use ABC decorators, inheriting from metaclass ABCMeta, and mark the function that needs to be "traited" with @abstractmethod. any class that then inherits from the base then is *required* to override (have) that method. more on that here:

    https://docs.python.org/3/library/abc.html

    lkcl, you *really* should learn Rust.
    what is the justification? i am not going to learn a language that has no use-case and no purpose, particularly one whose underlying syntax is unreadable as plain english.
    • the linux kernel is in c. we need to develop linux kernel drivers.
    • u-boot is in c. we need to port u-boot to Libre-SOC.
    • unit tests are written in pure assembler.
    • binutils, which we need, is written in c
    • both gcc and llvm are both written in c++.
    • ffmpeg is written in c++
    • gem5 is in mixed c++ and python
    • cavatools is in mixed c with python-based generator/compiler scripts
    that pretty much takes care of the next 3 years of development of Libre-SOC: at no point in that will rust be *immediately* useful, so why do i need to spend 6 months learning it?

    each of those dependencies above are multi-DECADE projects and above. any time spent replacing any of those by rewriting them in rust, unnecessarily, become themselves massive multi-DECADE projects, representing a massive distraction and diversion away from the goal that's been set (and funded by NLnet). look at how long GNU/Hurd, one of my favourite alternative kernels, took: they simply couldn't keep up.

    therefore, given the time pressure and the responsibility that we have to honour our obligations to NLnet, any time that i spend learning rust is actually a pretty irresponsible use of my time.

    bottom line is, we have to be really tough and realistic, and leverage what's *avalable*, rather than do what we *like* to do because it's a personal preferred interest.

    Leave a comment:


  • programmerjake
    replied
    Originally posted by programmerjake View Post

    Though imho we're over-using inheritance since python doesn't really have other good abstraction tools such as Rust's traits. If there was a HDL like nmigen but written in Rust that effectively used Rust's features (so more than just Verilog embedded in Rust), I would have jumped at the chance to write it in Rust. lkcl, you *really* should learn Rust.
    That Rust HDL could have all the parts that made BlueSpec so great -- guaranteed synthesizability, strong typing, good type checking, expressive types, etc. Too bad BlueSpec was not an option due to its proprietary nature.

    Leave a comment:


  • programmerjake
    replied
    Originally posted by lkcl View Post

    VHDL cannot do object-orientated multiple inheritance HDL, cannot do classes at all, is not 3rd on the TIOBE index and is not known by 30% of the world's programmers.

    quite simple really (what jacob said, above)
    Though imho we're over-using inheritance since python doesn't really have other good abstraction tools such as Rust's traits. If there was a HDL like nmigen but written in Rust that effectively used Rust's features (so more than just Verilog embedded in Rust), I would have jumped at the chance to write it in Rust. lkcl, you *really* should learn Rust.

    Leave a comment:


  • lkcl
    replied
    Originally posted by monty11ez View Post

    I see nmigen is being used instead of verilog, but why not VHDL?
    VHDL cannot do object-orientated multiple inheritance HDL, cannot do classes at all, is not 3rd on the TIOBE index and is not known by 30% of the world's programmers.

    quite simple really (what jacob said, above)

    Leave a comment:

Working...
X