<p>Yes.</p>
<p>If you don't like assembly programming, it's probably not the profession for you. The entire fundamental way a computer works can be learned through the ISA. If you understand how to program a machine using that, you will ingrain concepts that make it effortless to learn and apply and technology on top, so long as you have the will to continue to learn if it is required as the stack seems to needlessly and endlessly grows.</p>
<p>In short, programming in any higher level language is ultimately programming a machine, and if you don't enjoy the details, you probably won't last very long as a programmer, or a least a very good, highly paid one, or one with great skills if you go more of the FOSS route. These two paths are not mutually exclusive either.</p>

CC BY-SA 4.0
2021-02-28T05:39:12.527Z
Hi Layke, welcome to [cseducators.se]!  Without further expansion, this is a low-quality answer.  It would be helpful if you edited it to provide further justification to your position.
Ben I.
CC BY-SA 4.0
2021-02-28T16:11:54.180Z
OK, will comply!
Layke Findley
CC BY-SA 4.0
2021-02-25T23:36:55.453Z
2021-02-28T16:14:48.577Z
2021-02-28T16:14:48.577Z
Layke Findley
<p>To me, it depends on whether you are really teaching computer "science" or coding/programming.</p>

<p>If this is a genuine "science" course for math and hard science majors, I would teach assembly language early. It underpins the logic structures of most computer languages and many important commands, so if your students are interested in data structures and management, and the "logic" of computation (down to things like electric circuits and networks), assembly language is the way to go.</p>

<p>That said, it is not suitable for <em>most</em> students. Here, you are talking about "cross over" users who are more interested in coding which they will use to create programs than the underlying science. Put another way, these students want to learn "what" rather than "why."</p>

<p>In short, if I were structuring a college department, I would offer an assembly language <em>option</em> but not be surprised if only a few students took advantage of it. </p>

CC BY-SA 3.0
2017-06-11T03:43:41.220Z
2017-06-11T03:43:41.220Z
Tom Au
<p>I think there is <strong>very limited benefit</strong> in teaching assembly so early, and it's more likely to just scare away your students.</p>

<p>When I started learning programming, I thought bare-metal OS development was really interesting, and I started to learn about it (mainly through <a href="http://wiki.osdev.org/Main_Page" rel="noreferrer">OSDev</a>). But frankly, assembly was <strong>far</strong> beyond my level at that point, and it was hard to get <em>anywhere</em> beyond the tutorials they give. Consider that:</p>

<ul>
<li><p>Beginners often have problems with learning the <em>syntax</em> of the language, and the underlying conceptual problems (<em>"how do I design this?"</em>). Your students may not be ready for that after an introductory class—learning the concepts and thought processes (how to <em>think</em> like a programmer) is far more important than any language, and assembly only clouds that by making you think about memory, registers, jumps, etc.</p></li>
<li><p>Your students probably <strong>won't</strong> ever need assembly, and they almost certainly won't be writing much unless they go into fields like embedded development, OS development, etc. Even then, it's more likely that C (or a similar low-level language) will be used.</p></li>
<li><p>Assembly is <strong>intimidating</strong>. It's not something that it easy to read, understand, and write. Aside from the technical problems of teaching and learning, it's just <em>scary</em>, and when I tried to learn assembly, it just led to frustration and not a lot of progress.</p></li>
</ul>

<p>My opinion is that you should develop the higher-level concepts first, and make sure your students have a solid understanding of how to write code logically. Then, you can begin to 'remove the stabilisers', introduce memory management, and then finally lead to assembly, if that's what you want to teach.</p>

CC BY-SA 3.0
2017-07-11T02:09:58.990Z
I'm a bits and bytes guy. I learned back in the day when, to build something decently fast, you'd write your program in assembly, transcode it to decimal numbers, then "poke" it into RAM. As recently as 10 years ago I was on a project where the only way to accomplish what we needed (super fast RFC 4122 compliant UUID on z Series architecture) was to build it in assembly. But that is the only time I have used assembly seriously since the early 1990's.
pojo-guy
CC BY-SA 3.0
2017-05-23T15:55:40.307Z
Is it possible that the "scare" intimidation factor is a modern myth?  Or perhaps a result using too high a level language for too long?  The CARDIAC computer fit on one sheet of cardboard, and a class of  (IIRC) mostly non-STEM undergrads seemed to have no problems with programming it for an assignment.  And plenty (perhaps tens to hundreds of thousands?) of 14-17 year old kids learned to poke 6502 asm instructions.
hotpaw2
CC BY-SA 3.0
2017-05-23T16:01:34.347Z
@hotpaw2 I think it'll be hard to find an answer to that, but it's an interesting idea. I'd conjecture it's more a case of "I only learned 6502 assembly, so it was easy for me" being said by those who **did** thrive, and anyone who was unable to make the jump simply dropped out and gave up completely. I'll have a look round to see if I can find any research about how students learn in assembly, compared to a higher language, though.
Aurora0001
CC BY-SA 3.0
2017-05-23T21:33:32.617Z
“they almost certainly won't be writing much unless they go into fields like embedded development, OS development, etc.” — or even if they do. I am an embedded OS developer and I write maybe a handful of lines of assembly a year. In a busy year.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-05-24T22:37:48.820Z
The point would likely not be to train students how to write applications in assembly language, but more so that they learn enough about (near 1-to-1) machine code, to better understand how a CPU/processor actually carries out the real work.
hotpaw2
CC BY-SA 3.0
2017-05-25T14:55:00.347Z
@hotpaw2 Ah, right, sorry about that; it appears I've missed the point a little bit. I think the answer would depend on what language you plan to teach—a Python class probably wouldn't need an awareness of assembly just yet, but a C/C++ class might find it helpful. I'll revise my answer a little if you edit with that info in the question.
Aurora0001
CC BY-SA 3.0
2017-05-30T12:22:27.257Z
The scare/intimidation factor exists, to a degree. The affected students aren't "scared" of doing it, or of programming in general, rather they decide that "that's too much work." Especially when dealing with modern youth in the larger countries, cost-benefit analysis seems to be automatically performed at every turn, and in such an analysis assembly creates the impression that the effort far out weighs the gains.
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-23T05:11:14.743Z
Nice answer, definitely agree it's not appropriate for people who don't know how to think of the right algo for simple stuff.  Asm is *much* easier to learn after you understand pointers (e.g. in C).  I found it pretty straightforward to learn from looking at how a compiler implemented the logic of my code using asm.  Once you have the mental model of registers as the architectural state, and each instruction doing something specific to that state, you understand the building blocks you can use to implement algorithms.
Peter Cordes
CC BY-SA 3.0
2018-02-23T05:27:40.517Z
I wouldn't say it's hard to read, though.  Almost all computer languages are hard if you don't know them, so yes of course it's hard for beginners to read, but not a lot worse than C unless you don't even understand what registers are.  e.g. once you know one C-like language, you can make some sense of most other languages that use similar syntax.  With asm, I can usually make some sense of assembly language for architectures I barely know anything about, because usually the mnemonics + context are enough of a hint to figure out load / store / move.
Peter Cordes
CC BY-SA 3.0
2018-02-23T05:31:50.733Z
And BTW, OS-dev is a giant complication beyond just creating working algorithms in user-space.  Knowing some (or a lot) of asm is useful for performance tuning: e.g. looking at compiler output to see where you could [tweak the source to help the compiler](https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat/40355466#40355466), or looking at `perf` (HW performance counter profiles), and none of that has anything to do with writing drivers or setting up x86 IDT/GDT / segment registers (or making BIOS calls).
Peter Cordes
CC BY-SA 3.0
2017-05-23T15:28:12.563Z
2017-05-23T15:28:12.563Z
Aurora0001
<p>Yes: Some machine level behaviour is important at an early stage, to retain a diverse interest in the subject.</p>

<p>Some students will find it necessary to understand what a computer is doing 'under the hood', but others will have massive problems understanding how high level constructs can be broken down into simple load/add/store sequences.</p>

<p>Web simulators like <a href="http://www.peterhigginson.co.uk/RISC/" rel="nofollow noreferrer">Peter Higginson's RISC simulator</a> definately need to be presented, and I've had good success in modelling a Fetch/Decode/Execute pipeline as a group activity, where assembly language is a key part of enabling the activity.</p>

<p>However, I think it is the simple load/store (or RISC) architecture which is the key thing to describe, rather than the details of the assembly language. Using a simple instruction set is just a natural part of explaining this type of architecture.</p>

<p>If you focus just on the higher level languages, you'll probably not notice, but the students who have a more practical view of physics/electricity (or just how machines work) will forever be wondering what happens before their code gets to <code>main()</code>. These are the students who will go on to be embedded developers/ASIC designers or CPU architects (or rocket engineers).</p>

CC BY-SA 3.0
2018-02-23T06:01:02.057Z
... or they'll become compiler developers / performance tuning experts.  I got into computer programming after messing around with electronics / digital logic as a hobby in high school, and I've always loved knowing how things *really* work.  And now I code-golf in x86 machine code for fun :P
Peter Cordes
CC BY-SA 3.0
2017-05-23T15:31:14.413Z
2018-02-23T08:31:50.347Z
2018-02-23T08:31:50.347Z
Sean Houlihane
<p>I don't think there's much point teaching students to write assembly code purely for the sake of it. There are more useful and productive tools / languages / concepts that would be a better use of time. However, I'm a big fan of giving students some exposure to assembly code in order to teach some key concepts rather than skills:</p>

<p>Keen students often want to know the answer to the following questions:</p>

<p>1) How does a computer actually work?</p>

<p>2) What makes one computer faster than another?</p>

<p>It's hard to answer those questions fully without having a clear grasp of the fetch / decode / execute cycle. If students understand how computers store and process instructions there are huge consequences on the programs they can go on to create in terms of efficiency, reliability, performance and robustness. </p>

<p>If the 'introductory course' is an intro to programming generally, I'd probably avoid assembler. If it's an introduction to Computer Science which includes more than just writing code, I'd say some exposure to assembler is pretty essential. </p>

<p>I use <a href="http://tanks.withcode.uk/" rel="noreferrer">tanks.withcode.uk</a>  as a Little Man Computer CPU simulator that controls little tanks that students have to program around an obstacle course. At the end of that module I don't really mind if students can't remember how to write LMC code but I do expect them to be able to explain the fetch / execute cycle. The brighter students will also be able to explain the performance and security implications of the Von Neumann processor architecture.</p>

<p>This <a href="https://www.youtube.com/watch?v=9JgtS8XH-X0" rel="noreferrer">video</a> explains how LMC assembly can help explain some key CS concepts.</p>

<p>If nothing else, briefly exposing students to assembler programming makes them appreciate how much easier writing code is in a high-level language. </p>

CC BY-SA 3.0
2017-06-14T06:36:28.570Z
Welcome to CSeducators Stack Exchange! This is a very good answer, and quite to the point. Well done
ItamarG3
CC BY-SA 3.0
2017-06-14T06:33:40.000Z
2017-06-14T06:33:40.000Z
pddring
<p>Teaching how to <em>write</em> assembly is questionable at best.</p>

<p>Teaching how to <em>read</em> assembly is IMHO crucial, and comes naturally as a part of C/C++ curriculum. For example, try to explain what atomics are, and how they are not black magic, without referring to concepts from the assembly realm.</p>

CC BY-SA 3.0
2017-07-11T01:58:22.650Z
It helps that C is essentially structured PDP-11 Assembly language  :D
pojo-guy
CC BY-SA 3.0
2017-05-24T22:31:13.430Z
2017-05-24T22:31:13.430Z
user58697
<p>While there is a natural appeal to teaching assembly programming (hey, we can build everything up from first principals!), early students really need to master sequencing and organization at a higher level first.  There is a surprising amount of abstract thought going on in looping and determining ending conditions even without limiting your branching cases to <code>ZERO</code> and <code>NEGATIVE</code>, or having to worry about whether your <code>mod</code> operation just overwrote the <code>B</code> register.</p>

<p>I would avoid doing it as your first activity.  That said, if you <em>do</em> want to go early into assembly programming, <a href="https://tomorrowcorporation.com/humanresourcemachine" rel="noreferrer">Human Resource Machine</a> is an extraordinary resource, and we purchased a site license for use at our school.  We currently use it before bringing the kids into <strong>6502</strong> Assembly.  They get instantly addicted, and it makes many of esoteric the concepts rather visual.</p>

CC BY-SA 3.0
2017-06-06T20:43:33.307Z
[TIS-100](http://www.zachtronics.com/tis-100/) is another great resource in this area.
Adrir
CC BY-SA 3.0
2017-05-23T15:39:14.063Z
2017-05-23T15:39:14.063Z
Ben I.
<p>We need to separate the ideal of teaching a student how to be a fully competent assembly programmer, from the utility of using machine-level things like stacks and registers to help them build a model in their mind of what is going on. </p>

<p>For any given model of program execution, like flow charts or state diagrams, some students will take to it easily others will struggle. So I see the main issue is picking the model of execution that helps the student understand it.</p>

<p>Some things like pointers and arrays map directly to a <em>mechanical</em> view of the program and its data. Function calls can be thought of as nested sheets of variables and some students are fine with that. Others find it too abstract and the mechanical view of function calls where addresses are pushed into a what is in effect an array called the stack is <em>easier</em> to understand (for some) even though it has far more working parts.</p>

<p>To me this is an example of deeper issue, in teaching we must use our judgement in choosing a high level description of some part of a programming which has fewer parts, each of which is harder to grasp, or to explain a mechanism of a larger number of smaller pars, each of which is easier to understand.</p>

CC BY-SA 3.0
2018-02-23T06:13:03.587Z
Understanding that C compiles to asm is useful in debugging C programs with undefined behaviour.  e.g. if your program does something that shouldn't be possible, or crashes in a really weird way, then you probably did something wrong with a pointer to a local variable and stepped on something in the call stack.  IDK how far this gets you if you don't actually know asm (just that it exists), and don't have the expertise to backtrack from the symptoms to *what* might have been overwritten, though.
Peter Cordes
CC BY-SA 3.0
2017-06-14T09:43:29.563Z
2017-06-20T11:47:10.203Z
2017-06-20T11:47:10.203Z
Dominic Connor Quant Headhunt
<p>To very loosely paraphrase a famous man, "it depends on what the definition of 'teach' is." A few other answers have sort of approached this point, but none have quite said it.</p>

<p>There is a difference between introducing the fact that assembly language exists and explaining the purpose it serves, and going all out and instructing students in the meaning of each assembly instruction and having them write complete programs in assembly language.</p>

<p>Yes, assembly language is scary, but that alone isn't a good reason to shy away from teaching it. Many people who haven't been exposed to computer science think the entire field is intimidating.</p>

<p>For decades now, novices have basically had the options of learning to code in either high-level programming languages or REALLY-high-level programming languages*. Naturally, that leads to some disconnect about what's actually going on between the code and the processor. It's important for programmers to know that that space is filled by an ordered, understandable process, not magic. But anything more than that (and, arguably, even that much) can wait until after the introductory level.</p>

<p>Assembly is, quite frankly, too low-level for the kinds of thinking that introductory courses are intended to develop. The idea is to get students thinking about loops and lists and stacks and trees; algorithms and data structures. Talking about moving values from register to register hides the forest for the, um, other kind of trees.</p>

<p>Once students get past the first few courses and decide they want to stick with the program, then throw assembly into the mix along with other "necessary but more advanced" topics, like P/NP, I say.</p>

<p>* Compare to "once upon a time," when the default newbie programming language was C, which was a lot closer to assembly, and my answer might have been different.</p>

CC BY-SA 3.0
2017-06-21T21:15:20.397Z
Regarding the little apology I just ripped out of your answer, no need to apologize. We're glad you found us :)
Ben I.
CC BY-SA 3.0
2017-06-21T21:37:59.270Z
@BenI. Cheers. I usually figure the kind of people who care about the apology will be angry about not getting one but the kind of people who don't care won't mind seeing one (or quietly editing it out).
Piyush Parikh
CC BY-SA 3.0
2017-06-21T21:08:08.823Z
2017-06-21T21:13:38.183Z
2017-06-21T21:13:38.183Z
Piyush Parikh
<p>I haven't seen this in the thread yet so I thought I'd add it.</p>

<p>I haven't been in any environment where I've felt that starting low level makes sense but I've met others that do. YEARS ago  Noam Nisan and Shimon Schocken wrote <a href="http://www.nand2tetris.org/book.php" rel="nofollow noreferrer">The Elements of Computing System</a> which builds things from the ground up and I recently learned about <a href="http://www.nand2tetris.org/" rel="nofollow noreferrer">this course</a> using the book. I haven't vetted the course but it might be a useful resource.</p>

CC BY-SA 3.0
2017-06-20T11:52:19.733Z
2017-06-20T11:54:10.373Z
2017-06-20T11:54:10.373Z
Mike Zamansky
<p>CS50 AP -- the adaptation I teach for AP CS Principles -- has a lesson on the compilation process in C. The full scope of the lesson can be found <a href="https://ap.cs50.net/curriculum/2/compiling/" rel="nofollow noreferrer">here</a>.</p>

<p>While the lesson provides a broad overview of the process, it does expose students to the steps needed to go from source code to assembly code to machine code. As a result it makes understanding assembly relevant. It could very easily be used as a stand-alone lesson.</p>

<p>The programming challenge for this lesson -- <a href="http://docs.cs50.net/2016/ap/problems/reverse/reverse.html" rel="nofollow noreferrer">Reverse Engineer</a> -- focuses on the very basics of understanding assembly and tasks students with translating assembly instructions into a small C program. It's certainly not a full unit, but something of this scope does give a good introduction to assembly and allows it to be a reference point as the class progresses.</p>

<p>At the intro level this is probably the right amount of assembly to use: just enough to make them aware of it (and to motivate further study) but not too much that it creates more confusion than understanding.</p>

CC BY-SA 3.0
2017-05-27T02:11:14.670Z
2017-05-27T02:11:14.670Z
Peter
<p>Should ye ole' fashioned assembly language be taught to help students develop a sense of how actual underlying computational hardware supports/allows running their higher-level or more abstract software?</p>

<p>Something with (a limited amount of) a linear address space (global state memory) and a program counter with jumps (conditional control flow or GOTOs).</p>

<p>Using something like Knuth's MIX, or the CARDIAC cardboard computer (this was actually used to teach programming in an introductory computing for non-programmers course I audited at Berkeley in the late '70's), or perhaps an emulator for an 8-bit retro-computer (such as Apple II or Altair) that can run inside a web browser.</p>

<curriculum-design><assembly>
Should assembly language be taught in an introductory course (or soon after)?
# Should assembly language be taught in an introductory course (or soon after)?

(Asked by: username_0 on 2017-05-23)

Should ye ole' fashioned assembly language be taught to help students develop a sense of how actual underlying computational hardware supports/allows running their higher-level or more abstract software?

Something with (a limited amount of) a linear address space (global state memory) and a program counter with jumps (conditional control flow or GOTOs).

Using something like Knuth's MIX, or the CARDIAC cardboard computer (this was actually used to teach programming in an introductory computing for non-programmers course I audited at Berkeley in the late '70's), or perhaps an emulator for an 8-bit retro-computer (such as Apple II or Altair) that can run inside a web browser.

**Tags:** curriculum-design, assembly


---

## 11 answers

### Answer by username_4 on 2017-05-23. Score: 23

I think there is **very limited benefit** in teaching assembly so early, and it's more likely to just scare away your students.

When I started learning programming, I thought bare-metal OS development was really interesting, and I started to learn about it (mainly through [OSDev](http://wiki.osdev.org/Main_Page)). But frankly, assembly was **far** beyond my level at that point, and it was hard to get *anywhere* beyond the tutorials they give. Consider that:

* Beginners often have problems with learning the *syntax* of the language, and the underlying conceptual problems (*"how do I design this?"*). Your students may not be ready for that after an introductory class—learning the concepts and thought processes (how to *think* like a programmer) is far more important than any language, and assembly only clouds that by making you think about memory, registers, jumps, etc.
* Your students probably **won't** ever need assembly, and they almost certainly won't be writing much unless they go into fields like embedded development, OS development, etc. Even then, it's more likely that C (or a similar low-level language) will be used.
* Assembly is **intimidating**. It's not something that it easy to read, understand, and write. Aside from the technical problems of teaching and learning, it's just *scary*, and when I tried to learn assembly, it just led to frustration and not a lot of progress.

My opinion is that you should develop the higher-level concepts first, and make sure your students have a solid understanding of how to write code logically. Then, you can begin to 'remove the stabilisers', introduce memory management, and then finally lead to assembly, if that's what you want to teach.

> **Comments:**
> **username_0**: Is it possible that the "scare" intimidation factor is a modern myth?  Or perhaps a result using too high a level language for too long?  The CARDIAC computer fit on one sheet of cardboard, and a class of  (IIRC) mostly non-STEM undergrads seemed to have no problems with programming it for an assignment.  And plenty (perhaps tens to hundreds of thousands?) of 14-17 year old kids learned to poke 6502 asm instructions.  
> **username_4**: @username_0 I think it'll be hard to find an answer to that, but it's an interesting idea. I'd conjecture it's more a case of "I only learned 6502 assembly, so it was easy for me" being said by those who **did** thrive, and anyone who was unable to make the jump simply dropped out and gave up completely. I'll have a look round to see if I can find any research about how students learn in assembly, compared to a higher language, though.  
> **username_6**: “they almost certainly won't be writing much unless they go into fields like embedded development, OS development, etc.” — or even if they do. I am an embedded OS developer and I write maybe a handful of lines of assembly a year. In a busy year.  
> **username_0**: The point would likely not be to train students how to write applications in assembly language, but more so that they learn enough about (near 1-to-1) machine code, to better understand how a CPU/processor actually carries out the real work.  
> **username_4**: @username_0 Ah, right, sorry about that; it appears I've missed the point a little bit. I think the answer would depend on what language you plan to teach—a Python class probably wouldn't need an awareness of assembly just yet, but a C/C++ class might find it helpful. I'll revise my answer a little if you edit with that info in the question.  
> **username_7**: The scare/intimidation factor exists, to a degree. The affected students aren't "scared" of doing it, or of programming in general, rather they decide that "that's too much work." Especially when dealing with modern youth in the larger countries, cost-benefit analysis seems to be automatically performed at every turn, and in such an analysis assembly creates the impression that the effort far out weighs the gains.  
> **username_5**: I'm a bits and bytes guy. I learned back in the day when, to build something decently fast, you'd write your program in assembly, transcode it to decimal numbers, then "poke" it into RAM. As recently as 10 years ago I was on a project where the only way to accomplish what we needed (super fast RFC 4122 compliant UUID on z Series architecture) was to build it in assembly. But that is the only time I have used assembly seriously since the early 1990's.  
> **username_8**: Nice answer, definitely agree it's not appropriate for people who don't know how to think of the right algo for simple stuff.  Asm is *much* easier to learn after you understand pointers (e.g. in C).  I found it pretty straightforward to learn from looking at how a compiler implemented the logic of my code using asm.  Once you have the mental model of registers as the architectural state, and each instruction doing something specific to that state, you understand the building blocks you can use to implement algorithms.  
> **username_8**: I wouldn't say it's hard to read, though.  Almost all computer languages are hard if you don't know them, so yes of course it's hard for beginners to read, but not a lot worse than C unless you don't even understand what registers are.  e.g. once you know one C-like language, you can make some sense of most other languages that use similar syntax.  With asm, I can usually make some sense of assembly language for architectures I barely know anything about, because usually the mnemonics + context are enough of a hint to figure out load / store / move.  
> **username_8**: And BTW, OS-dev is a giant complication beyond just creating working algorithms in user-space.  Knowing some (or a lot) of asm is useful for performance tuning: e.g. looking at compiler output to see where you could [tweak the source to help the compiler](https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat/40355466#40355466), or looking at `perf` (HW performance counter profiles), and none of that has anything to do with writing drivers or setting up x86 IDT/GDT / segment registers (or making BIOS calls).  

---

### Answer by username_2 on 2017-05-23. Score: 8

While there is a natural appeal to teaching assembly programming (hey, we can build everything up from first principals!), early students really need to master sequencing and organization at a higher level first. There is a surprising amount of abstract thought going on in looping and determining ending conditions even without limiting your branching cases to `ZERO` and `NEGATIVE`, or having to worry about whether your `mod` operation just overwrote the `B` register.

I would avoid doing it as your first activity. That said, if you *do* want to go early into assembly programming, [Human Resource Machine](https://tomorrowcorporation.com/humanresourcemachine) is an extraordinary resource, and we purchased a site license for use at our school. We currently use it before bringing the kids into **6502** Assembly. They get instantly addicted, and it makes many of esoteric the concepts rather visual.

> **Comments:**
> **username_13**: [TIS-100](http://www.zachtronics.com/tis-100/) is another great resource in this area.  

---

### Answer by username_9 on 2017-05-23. Score: 7

Yes: Some machine level behaviour is important at an early stage, to retain a diverse interest in the subject.

Some students will find it necessary to understand what a computer is doing 'under the hood', but others will have massive problems understanding how high level constructs can be broken down into simple load/add/store sequences.

Web simulators like [username_17 Higginson's RISC simulator](http://www.peterhigginson.co.uk/RISC/) definately need to be presented, and I've had good success in modelling a Fetch/Decode/Execute pipeline as a group activity, where assembly language is a key part of enabling the activity.

However, I think it is the simple load/store (or RISC) architecture which is the key thing to describe, rather than the details of the assembly language. Using a simple instruction set is just a natural part of explaining this type of architecture.

If you focus just on the higher level languages, you'll probably not notice, but the students who have a more practical view of physics/electricity (or just how machines work) will forever be wondering what happens before their code gets to `main()`. These are the students who will go on to be embedded developers/ASIC designers or CPU architects (or rocket engineers).

> **Comments:**
> **username_8**: ... or they'll become compiler developers / performance tuning experts.  I got into computer programming after messing around with electronics / digital logic as a hobby in high school, and I've always loved knowing how things *really* work.  And now I code-golf in x86 machine code for fun :P  

---

### Answer by username_10 on 2017-06-14. Score: 5

I don't think there's much point teaching students to write assembly code purely for the sake of it. There are more useful and productive tools / languages / concepts that would be a better use of time. However, I'm a big fan of giving students some exposure to assembly code in order to teach some key concepts rather than skills:

Keen students often want to know the answer to the following questions:

1) How does a computer actually work?

2) What makes one computer faster than another?

It's hard to answer those questions fully without having a clear grasp of the fetch / decode / execute cycle. If students understand how computers store and process instructions there are huge consequences on the programs they can go on to create in terms of efficiency, reliability, performance and robustness.

If the 'introductory course' is an intro to programming generally, I'd probably avoid assembler. If it's an introduction to Computer Science which includes more than just writing code, I'd say some exposure to assembler is pretty essential.

I use [tanks.withcode.uk](http://tanks.withcode.uk/) as a Little Man Computer CPU simulator that controls little tanks that students have to program around an obstacle course. At the end of that module I don't really mind if students can't remember how to write LMC code but I do expect them to be able to explain the fetch / execute cycle. The brighter students will also be able to explain the performance and security implications of the Von Neumann processor architecture.

This [video](https://www.youtube.com/watch?v=9JgtS8XH-X0) explains how LMC assembly can help explain some key CS concepts.

If nothing else, briefly exposing students to assembler programming makes them appreciate how much easier writing code is in a high-level language.

> **Comments:**
> **username_11**: Welcome to CSeducators Stack Exchange! This is a very good answer, and quite to the point. Well done  

---

### Answer by username_12 on 2017-05-24. Score: 5

Teaching how to *write* assembly is questionable at best.

Teaching how to *read* assembly is IMHO crucial, and comes naturally as a part of C/C++ curriculum. For example, try to explain what atomics are, and how they are not black magic, without referring to concepts from the assembly realm.

> **Comments:**
> **username_5**: It helps that C is essentially structured PDP-11 Assembly language  :D  

---

### Answer by username_14 on 2017-06-14. Score: 4

We need to separate the ideal of teaching a student how to be a fully competent assembly programmer, from the utility of using machine-level things like stacks and registers to help them build a model in their mind of what is going on.

For any given model of program execution, like flow charts or state diagrams, some students will take to it easily others will struggle. So I see the main issue is picking the model of execution that helps the student understand it.

Some things like pointers and arrays map directly to a *mechanical* view of the program and its data. Function calls can be thought of as nested sheets of variables and some students are fine with that. Others find it too abstract and the mechanical view of function calls where addresses are pushed into a what is in effect an array called the stack is *easier* to understand (for some) even though it has far more working parts.

To me this is an example of deeper issue, in teaching we must use our judgement in choosing a high level description of some part of a programming which has fewer parts, each of which is harder to grasp, or to explain a mechanism of a larger number of smaller pars, each of which is easier to understand.

> **Comments:**
> **username_8**: Understanding that C compiles to asm is useful in debugging C programs with undefined behaviour.  e.g. if your program does something that shouldn't be possible, or crashes in a really weird way, then you probably did something wrong with a pointer to a local variable and stepped on something in the call stack.  IDK how far this gets you if you don't actually know asm (just that it exists), and don't have the expertise to backtrack from the symptoms to *what* might have been overwritten, though.  

---

### Answer by username_15 on 2017-06-21. Score: 3

To very loosely paraphrase a famous man, "it depends on what the definition of 'teach' is." A few other answers have sort of approached this point, but none have quite said it.

There is a difference between introducing the fact that assembly language exists and explaining the purpose it serves, and going all out and instructing students in the meaning of each assembly instruction and having them write complete programs in assembly language.

Yes, assembly language is scary, but that alone isn't a good reason to shy away from teaching it. Many people who haven't been exposed to computer science think the entire field is intimidating.

For decades now, novices have basically had the options of learning to code in either high-level programming languages or REALLY-high-level programming languages\*. Naturally, that leads to some disconnect about what's actually going on between the code and the processor. It's important for programmers to know that that space is filled by an ordered, understandable process, not magic. But anything more than that (and, arguably, even that much) can wait until after the introductory level.

Assembly is, quite frankly, too low-level for the kinds of thinking that introductory courses are intended to develop. The idea is to get students thinking about loops and lists and stacks and trees; algorithms and data structures. Talking about moving values from register to register hides the forest for the, um, other kind of trees.

Once students get past the first few courses and decide they want to stick with the program, then throw assembly into the mix along with other "necessary but more advanced" topics, like P/NP, I say.

\* Compare to "once upon a time," when the default newbie programming language was C, which was a lot closer to assembly, and my answer might have been different.

> **Comments:**
> **username_2**: Regarding the little apology I just ripped out of your answer, no need to apologize. We're glad you found us :)  
> **username_15**: @BenI. Cheers. I usually figure the kind of people who care about the apology will be angry about not getting one but the kind of people who don't care won't mind seeing one (or quietly editing it out).  

---

### Answer by username_16 on 2017-06-20. Score: 3

I haven't seen this in the thread yet so I thought I'd add it.

I haven't been in any environment where I've felt that starting low level makes sense but I've met others that do. YEARS ago Noam Nisan and Shimon Schocken wrote [The Elements of Computing System](http://www.nand2tetris.org/book.php) which builds things from the ground up and I recently learned about [this course](http://www.nand2tetris.org/) using the book. I haven't vetted the course but it might be a useful resource.


---

### Answer by username_17 on 2017-05-27. Score: 3

CS50 AP -- the adaptation I teach for AP CS Principles -- has a lesson on the compilation process in C. The full scope of the lesson can be found [here](https://ap.cs50.net/curriculum/2/compiling/).

While the lesson provides a broad overview of the process, it does expose students to the steps needed to go from source code to assembly code to machine code. As a result it makes understanding assembly relevant. It could very easily be used as a stand-alone lesson.

The programming challenge for this lesson -- [Reverse Engineer](http://docs.cs50.net/2016/ap/problems/reverse/reverse.html) -- focuses on the very basics of understanding assembly and tasks students with translating assembly instructions into a small C program. It's certainly not a full unit, but something of this scope does give a good introduction to assembly and allows it to be a reference point as the class progresses.

At the intro level this is probably the right amount of assembly to use: just enough to make them aware of it (and to motivate further study) but not too much that it creates more confusion than understanding.


---

### Answer by username_1 on 2021-02-25. Score: 2

Yes.

If you don't like assembly programming, it's probably not the profession for you. The entire fundamental way a computer works can be learned through the ISA. If you understand how to program a machine using that, you will ingrain concepts that make it effortless to learn and apply and technology on top, so long as you have the will to continue to learn if it is required as the stack seems to needlessly and endlessly grows.

In short, programming in any higher level language is ultimately programming a machine, and if you don't enjoy the details, you probably won't last very long as a programmer, or a least a very good, highly paid one, or one with great skills if you go more of the FOSS route. These two paths are not mutually exclusive either.

> **Comments:**
> **username_2**: Hi Layke, welcome to [cseducators.se]!  Without further expansion, this is a low-quality answer.  It would be helpful if you edited it to provide further justification to your position.  
> **username_1**: OK, will comply!  

---

### Answer by username_3 on 2017-06-11. Score: 2

To me, it depends on whether you are really teaching computer "science" or coding/programming.

If this is a genuine "science" course for math and hard science majors, I would teach assembly language early. It underpins the logic structures of most computer languages and many important commands, so if your students are interested in data structures and management, and the "logic" of computation (down to things like electric circuits and networks), assembly language is the way to go.

That said, it is not suitable for *most* students. Here, you are talking about "cross over" users who are more interested in coding which they will use to create programs than the underlying science. Put another way, these students want to learn "what" rather than "why."

In short, if I were structuring a college department, I would offer an assembly language *option* but not be surprised if only a few students took advantage of it.


---

