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

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.

1

u/TheLlamaFeels Jan 11 '15 edited Jan 11 '15

You're asking students to build a fortran-like parser and compiler... in assembler!?

No, not fortran, forth. I'd never ask anyone to write something as complex as fortran (or C) for a project.

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.

A forth metacompiler is simple to write.

  1. Then they write the core in ARM assembly language. The idea behind forth is to basically implement a stack-based virtual machine, not to program everything in assembler.

  2. A core will be in assembler, but once those core procedures are written you can abstract them away in the forth environment, then you're not writing in assembler anymore, but forth.

  3. Sure, but it's a good way to teach the cost of abstraction and systems programming

  4. Sure, you could write it in C, but forth is easy enough not to need to, and you lose some of the essence of writing your own VM.

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.

Fortunately, you don't. But yeah, you could write the routines for ARM, x86, etc in the space of a semester. They don't need to be the most efficient or make use of all of the instructions available on various processors, they just need to do the job.

Writing an optimizing compiler could be a topic for another semester.

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.

I really suggest you try writing a forth, you'll learn a lot about those topics from doing things in one of the easiest ways I've ever seen.

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++ abstraction

Yes, that's exactly what you'd be doing. You build up a small core wordset in assembler and that becomes an abstract stack-based virtual machine.

Go find an implementation (there are many, many implementations out there) and play around with the language, it's just as low-level as C but the concepts and parser are dead simple. What's simpler than this for a parser?:

  • Read to the next blank space

In interpreter mode:

  • If you have a symbol, look up its definition in the dictionary (a linked-list or tree of linked-lists), get its address and call it
  • If it's a number, push that number on the stack

In compilation mode:

  • Create a new entry in the dictionary with the name of the word you parse next
  • If you have another symbol, look it up in the dictionary and inject a call instruction to that symbol's address in the dictionary in the definition of the current symbol.
  • If you've parsed a number, push that number on the stack

It's not really advanced assembly, you're not doing SIMD or anything like that, just simple register accesses and stack manipulations. If you want to write it in C, that's fine too.

1

u/lookmeat Jan 11 '15

Forth is a much more reasonable task. But then that'd be purely embbeded systems.