[deleted]
Rewrite Linux Kernel in Rust?
21–30 of 133 posts
Re: Rewrite Linux Kernel in Rust?
#22Earlier quoted context omitted.
Interestingly, in the language you actually wrote that complaint in : > you assign 5 to eax AT&T speaks English, basically. We move A to B. Destination goes last. Both seem sane enough. And in fact both get really balled up when you have three and four-argument instructions.
I'll grant that, but it's a programming language, so I kind of expect it to follow the order assignment does when I write in C++, C#, etc.
> I kind of expect it to follow the order assignment does when I write in C++, C#, etc.
There is no special precedence that should be applied to C. Similarity to C only imparts benefits to those that are fimilar with C-like languages or variants that follow that structure. That ends up being a lot of people because of how popular C and variants have been, but that's doesn't inherently make it better.
It's sort of a pet peeve of mine when people point out differences from C as problems without any objective facts to back up whether it actually is more or less useful in some aspects. If we never stood up to that type of thinking, we'd all by much poorer in the programming language department.
Re: Rewrite Linux Kernel in Rust?
#23Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it bein…
Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things too.
Re: Rewrite Linux Kernel in Rust?
#24I wonder what makes AT&T assembly syntax "objectively crap".
The best set of arguments I've seen against it: http://x86asm.net/articles/what-i-dislike-about-gas/
Re: Rewrite Linux Kernel in Rust?
#25This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.
I mean, the advantages of C++ are complexity management and the downside is its abstractness which is what Linus' argument was about (It is a behemoth compared to C therefore easy to make mistakes).
Rust might prove to be a possible candidate because it can help with safety. This is a different rationale than what the argument for C++ was about, so we cannot say.
The bigger problem I see is how premature the Rust eco-system and understanding is. It needs to go quite a long way people people start believing in it and before the language is well understood by more than a niche group of people who learn it just out of interest.
Re: Rewrite Linux Kernel in Rust?
#26Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it bein…
Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things…
Do you get anything with him? I was under the impression dereference safety wasn't a priority.
Re: Rewrite Linux Kernel in Rust?
#27I wonder what makes AT&T assembly syntax "objectively crap".
You need to explicitly specify what the parameter sizes and types are. Plus, the parameters are backwards compared to Intel syntax: Intel: mov eax, 5 AT&T: movl $5, %eax In basically every C-like programming language, you assign 5 to eax with `eax=5` not `5=eax`. I can also tell that I'm working with the `long` variant of `mov` just by looking at the types involved. Intel's syntax for memory access seems more natural…
Why would you expect assignment order to be similar? Nothing else about c syntax is shared.
If anything, at&t follows English: move literal 5 into register eax.
Re: Rewrite Linux Kernel in Rust?
#28Re: Rewrite Linux Kernel in Rust?
#29It would cease to be Linux, but by all means -- make it so!
BTW Redox OS (written in rust) originally supported Linux syscalls which I thought was a super cool feature.
Jorge Aparicio started steed, a libc implemented in rust for rust. It seems like a pretty interesting approach.
Re: Rewrite Linux Kernel in Rust?
#30Earlier quoted context omitted.
You need to explicitly specify what the parameter sizes and types are. Plus, the parameters are backwards compared to Intel syntax: Intel: mov eax, 5 AT&T: movl $5, %eax In basically every C-like programming language, you assign 5 to eax with `eax=5` not `5=eax`. I can also tell that I'm working with the `long` variant of `mov` just by looking at the types involved. Intel's syntax for memory access seems more natural…
Right, but the mnemonic reads better in AT&T then "move 5 to register eax" and Intel seems backwards.
It's what you get used to. I'm used to x86 being "dst,src". It never bothered me that on the Motorola 68000 it went "src,dst" as, it was what it was. Intel defined it one way, Motorola another way [1].
My gripe with AT&T style (and it's called AT&T because K&R wrote their assembler that way) is that it uses sigils to mark registers (something I've never seen any other assembler do) and specifically broke with the manufacturer's mnemonics. Yes, I can see why they did it that way (a consistent format for assembly across multiple architectures) but I don't necessarily agree with it (Go's assembler has gone father by not even bothering with the register names the manufacturer uses).
Almost forgot---another annoying aspect of AT&T is the use of "$" to designate an immediate value. Every assembler I used (prior to my exposure to Unix) used "#" for immediate value, and "$" for hexadecimal. But noooo, AT&T had to use "$" for immediate, and "0x" to designate hexadecimal and thus, I hit a brick wall each time I read code in AT&T format.
[1] Also interesting to note---Intel is little endian, Motorola is bigendian.