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

[programmerjake]

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.

[lkcl]

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.

[pal666]

libre-resistive-heater?

[lkcl]

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.

[programmerjake]

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:

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
}

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.).

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

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!

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.

[programmerjake]

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/opensource/why-aws-loves-rust-and-how-wed-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/05/why-the-developers-who-use-rust-love-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.

[lkcl]

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.

[programmerjake]

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.