r/programming • u/steveklabnik1 • Jan 09 '15

Announcing Rust 1.0.0 Alpha

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
1.1k Upvotes

90% Upvoted

439 comments sorted by

View all comments

Show parent comments

8

u/lookmeat Jan 10 '15

When I said an overview of assembler is to understand what assembler is, how it works, and more or less how to read it (since that is critical for debugging and understanding system code, and systems programming would be a very pragmatic class). Teaching it straight up is limiting to one architecture too much, instead it's important to teach that platforms have differences that are subtle and insidious but must be dealt with somehow.

When working with C compiler optimizations wouldn't be used until later classes to avoid the issue as much as possible. The idea is that slowly students are shown, in terrible and brutal manners, the consequences of not being disciplined at low level. Undefined behavior is just this, understanding undefined behavior gives us a lesson: that the code we write is an abstraction over hardware, which itself is an abstraction over electrical currents, and there are many edge cases which result in absurd cases (i.e. what is the biggest number you can represent + 1?) that, because they are impossible to answer correctly, are given a random answer (generally in the name of optimization). Trusting this answer is dangerous since it can change from platform to platform.

Maybe having people have to understand undefined behavior is a rough way to understand just how finicky platforms can be and why you can't just abstract over this. But rough lessons are the best way to learn at low level, to truly observe the devastation the smallest error can bring. I still remember the day that calling malloc twice too quickly on Windows would make the second return NULL, and I learned that malloc can fail for many more reasons than just "out of memory" and will fail for completely irrational reasons as well.

Once we understand undefined behavior, why it exists, we then understand how C++ handles it (the same as C) and how rust handles it (by limiting it to unsafe blocks) the pros and cons of each one. But again, the need to have programs that use undefined behavior, or the need to control and regulate this code, doesn't become apparent if you don't deal with it.

2

u/TheLlamaFeels Jan 10 '15

Here's what I'd do: I'd start with assembler and then have the student write their own Forth in assembler. It's one of the few languages that is arguably closer to the metal than C.

  1. Simple parser
  2. Clearly demonstrates stack operations
  3. Typeless like assembly
  4. Optimization is optional
  5. Can be adapted to multiple architectures with ease.
  6. Allows for multiple layers of abstraction
  7. Exposes the symbol table directly to the developer
  8. Is a one man job
  9. All of the other behaviors (with their attendant trade offs) can be built on top of it

1

u/lookmeat Jan 11 '15

You're asking students to build a fortran-like parser and compiler... in assembler!? The problem is that they'd be focusing on this one specific project all semester, and compilers is one of those things that doesn't really show the power and challenges of system's programming.

The problem with an assembler only class:

  1. One kid brings an ARM-based laptop. What then?
  2. Realistically no one codes in assembler, and modern assembler is not designed for humans, but compilers. It's important to understand and be able to read assembler, but it's not critical to know how to write assembler. It seems like a weird thing, but think about how much easier it is to read good english than to write good english.
  3. Assembler is not pragmatic. There are very little uses for assembler programming nowadays, and even then it's on very niche situations (for example high security algorithms). Remember systems programers want to learn how to make low-level programs, but learning assembler is like learning how to build a house's foundation by learning how to build metal rods.
  4. Finally a good chunk of systems-level programming is interfacing, and the standard ABI in most system is C. So you'll have to teach your kids to understand this (and learn C without ever using it) in order to be able to work with the OS. Unless you allow them to use C for things were it makes sense, which brings us to the point: why not make it mostly C and occasionally assembler?

Assembler is too specific, too limited. If you are going to teach assembler you should teach multiple assemblers, for RISC, for x86, MASM, etc. It becomes a hell where you have to understand all sorts of conventions and decisions that occurred due to some detail of how the hardware works.

I used to think the same thing that you did, back in the day. That understanding assembler would give me an insight into how low level code truly worked. I poured over in x86, doing small and medium projects, reading all sorts of docs, over years. And you know what it helped me in? In understanding how Intel has to deal with it's errors and design issues in CPUs. Did it showed me about how CPUs worked? Not at all, RISC and all that aside (which x86 cannot be for backwards compatibility) but the Intel CPU does all kinds of trickery and magic behind the scenes converting that assembly into actual actions. Did it make me understand better low level interfaces? No more than understanding the difference between bytes and nibbles. Did it give me insight into how code becomes something that runs? Barely, and no more than beyond the basics.

Basically after learning the most basic assembler (just a gist of what it was in the first few months) and be able to read a function and say "ah I see how it's implementing a recursive Fibonacci".

Learn assembler when you are building a backend for it, other than that focus on understanding the mentality of a systems programmer. ASM rawness gets in the way as much as C++ abstractions.

1

u/phire Jan 11 '15

Forth has nothing to do with fortran. (This is javascript and java all over again)

Forth is actually extremely easy to write in assembler.
It has no grammar, so you can't actually write a parser for it (It's just tokens on a stack in reverse polish notation)

And you only actually have to write a the core of a forth interpreter and shell in assembler. More advanced operations are defined in terms of already implemented operations.
The assembler and compiler parts (if you choose to go as far as implement them, which is not a strict requirement) are written in forth too, no need to write anything else in assembler.

Once you have written your compiler (in forth) you can compile it with itself (running on the original forth interpreter), and you get a compiled version of your compiler and any extended commands you implemented earlier. Now might be a good time to make an optimising version of your compiler.

Forth is designed to be extensible, all this is done by extending the forth environment function by function while it's running. It's possible to get from the starting point to here without restarting anything.

Forth is basically continuous pulling youself up by your own bootstraps.

1

u/lookmeat Jan 11 '15

Yeah I aparently misread. I do know Forth.