News for hackers. Stuff that matters.
Re:Rewrite Linux Kernel in Rust? by colejohnson66 on Saturday June 03, 2017 @10:21PM (#14479585)
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.
Re:Rewrite Linux Kernel in Rust? by ajross on Saturday June 03, 2017 @10:27PM (#14479599)
AT&T assembly style significantly predates C++ (and C# by like two decades), and co-evolved with C. And strictly this isn't an assignment, anyway. Assignment is an abstract operation in a programming language. This is a machine instruction[1] for a physical machine, which does exactly one thing.

[1] Pause while the peanut gallery points out that in fact there are like ninety six different instructions in x86 called some variant of "MOV". Yeah, yeah, we know.

Re:Rewrite Linux Kernel in Rust? by i336_ on Sunday June 04, 2017 @04:52AM (#14480452)
What.

When did `mov` get 96 different instructions?

Re:Rewrite Linux Kernel in Rust? by chipaca on Sunday June 04, 2017 @06:01AM (#14480616)
I think it's just a bit of hyperbole. I don't know enough of this to know whether http://c9x.me/x86/html/file_module_x86_id_176.html is complete, but it gives you a sense of it all. (also https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf if you haven't seen it)
Re:Rewrite Linux Kernel in Rust? by i336_ on Sunday June 04, 2017 @06:12AM (#14480650)
Huh, interesting.

Apparently there are 35 rows in the table at http://www.felixcloutier.com/x86/MOV.html (according to Chrome and `$0.childElementCount`). I only discovered gcc.godbolt.org links to documentation via context menu just the other day!

Regarding the PDF... ouch. Wonder if any executable obfuscators have tried that approach :P (and I also wonder what sort of overhead it has.)

Re:Rewrite Linux Kernel in Rust? by kbenson on Saturday June 03, 2017 @10:34PM (#14479618)
> 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? by hyperpape on Saturday June 03, 2017 @11:27PM (#14479749)
This does raise the question: which languages other than AT&T assembly put the value first?
Re:Rewrite Linux Kernel in Rust? by AstralStorm on Sunday June 04, 2017 @01:13AM (#14479996)
AT&T syntax puts the operator first, not the value. AT&T is Verb Subject Object. Intel is alien Verb Object Subject.

Many kinds of S expressions result in similar code. That would mean Lisp derivatives.

Re:Rewrite Linux Kernel in Rust? by tom_mellior on Sunday June 04, 2017 @05:55AM (#14480600)
> AT&T syntax puts the operator first, not the value.

If "operator" has any meaning in assembly language, it would have to refer to the opcode. Both variants have the opcode (mov/movl) first.

> AT&T is Verb Subject Object. Intel is alien Verb Object Subject.

Both "move 5 into EAX" and "move into EAX the value 5" are imperatives. Neither of them has a subject, or more precisely, the subject is omitted (https://en.wikipedia.org/wiki/Imperative_mood). In both of these, 5 is an object. "into EAX" is an adverbial phrase or something.

It's true that one sounds more alien than the other when forcibly translated to English. Then again, assembly language is not English, so that's neither here nor there.

Re:Rewrite Linux Kernel in Rust? by hyperpape on Sunday June 04, 2017 @08:46AM (#14481248)
Sloppy of me, but I meant value before the variable/register.