Not all of them do --- MIPS was very common once (now probably being replaced by RISC-V), and I've come across recent (<5 years old) lecture slides from Indian universities where they still use the 8086/88, 8051, 8080/8085/Z80, etc.
My university did that switch over in '18. The course originally taught MIPS but shifted to RISC-V, partially though because the book that they taught from was updated from MIPS to RISC-V. I really appreciated the switch, especially as RISC-V becomes more and more relevant.
Much as I also have never understood universities teaching to "teaching" architectures (DLX), or "teaching" languages (Eiffel - luckily removed from our curriculum before I started), at the same time I did not land a job based on having learned "practical" architectures 68k or MIPS either.
Assertions in e.g. python? Missing the 'contract view', but you could generate docs that pull in any assertions on input args or return value to do something like that.
A lot of my compsci education was in Pascal, which was not exactly a real-world language (though I guess Delphi had a dedicated niche for many years)
I actually think this was probably better than learning with real-world languages?
I believe it taught me to be a computer programmer. Not a Java guy or a C guy or a whatever guy. I think that was super valuable.
For assembly language we learned VAX assembly, which was already hilariously outdated, but again very valuable. It had a very beginner friendly instruction set, much more friendly than x86 which would have been the other realistic choice at the time.
Because x86/x64 is horribly CISC. I challenge you to list the instructions a current x64 processor runs in a table. You will get so lost in the extensions it does and does not support that you will give up.
Because Apple's M chips have not been on the market long enough for us to adjust, nor are there cheap versions we can pick up for our hardware labs.
Because phones are not good for teaching computer architecture. We want something with a large screen and keyboard.
If I were teaching computer architecture, I would use an ARM chip in a Raspberry Pi.
> If I were teaching computer architecture, I would use an ARM chip in a Raspberry Pi.
If I were, my students' first CPU would be something like a 6502 -- quite possibly God's perfect CPU architecture. Then move on to something more complicated, RISCy, and 32-bit.
Modern CPUs are too complicated to teach in a semester. Plus, the course is meant to teach how a CPU works at a conceptual level, not train students for x86 assembly programming.
I had an "Assembly" course in my undergrad that taught x86, we managed in in semester. But it was a separate class from Architecture (and had Architecture I as a pre-requisite). Granted it didn't get into the hyper-optimized / specialized instructions.
IIRC, I learned computer architecture with a mythical 13 instruction set ISA. The class started with the basics of using flip flops to build registers and memory, program counters, etc. We had to demonstrate the state of every register at a given line in assembly. We had to write our own assembly. Then we learned C and how to translate it into assembly. The dots were connected from logic gates to to a high level stack based programming language.
I got a lot of mileage out of that class. The knowledge easily translates to other ISAs I’ve encountered in my career.
That was basically what we did at my school. I have fond memories of writing an assembler in Perl to do the machine code assignment so I wouldn't have to calculate the jumps by hand
The answers don't really go into what I think is the main issue:
An introductory computer architecture course is generally starting from "here is what a transistor is" and hoping to end with "here is how basic computer games work" (e.g., nand2tetris). And has about 40 hours of instruction to do it.
Assembly is but a small part of the course. The ideal assembly language for such a course is one that is simple, something that you can let the interested student figure out how to implement it themselves with just a little bit of prompting. And frankly, most assembly languages aren't up to that task, even if you're willing to pretend that most of the ISA doesn't exist. x86 has issues with things like ModR/M or two-address instructions. ARM has things like r15-is-actually-the-program-counter-and-kinda-special. RISC-V coalesces most of the jump instructions into one or two instructions that is going to complete teaching subroutines in assembly (and also eschews condition codes).
At the end of the day, the stuff you're covering in introductory computer architecture is very far in almost every detail from how modern computers work, and it will take several courses on top of it to actually reach those details. The most important goal of such a course isn't to teach you how they work, it's to give you the information you need to understand the explanations of how they actually work.
One of the reasons why they used Scheme for MIT's 6.001 is because it was an obscure programming language. At the time, some incoming MIT freshmen were likely to have faffed about with computers in high school or before, learning languages such as BASIC or Pascal. Others would have had little to no computer exposure before entering university. Scheme, being a Lisp and having semantics that were quite different from BASIC, Pascal, or any other language such students were likely to encounter, allowed all students to begin on a more or less equal footing because the programming language used for pedagogy would have been equally unfamiliar to all of them.
Obscure CPUs have the same advantage. Plus with careful choice of architecture, or simply inventing your own, you make pedagogy much simpler because the architecture doesn't have all the complicated bits like branch predictors, register windows, speculative execution, etc. that modern CPUs have and you can focus on the basic, "must-have" components.
You can teach 8086 assembly which is still compatible with modern x86 and it only has like 20 instructions. It's lots of fun I made a whole bootable text editor an assembler and an almost finished lisp interpreter too.
Sure, but one of the fun things you'll want to do from assembler is put pixels or characters on the screen. They're memory mapped outside of segment 0, so you'll need to work with segments to do that.
No, not really. A couple of features of the architecture and instruction encoding which were historically used for segmentation remain on amd64, and these features are used to implement thread-local storage on every mainstream os targeting the arch, but amd64 is not a segmented architecture in any meaningful sense.
I think the 8086 has 117 instructions. It is a good example of a CISC, after all, with instructions like the one capable of copying a C string: REPNZ MOVSB.
While I have seen many claims that the 8086 has more than 20 thousand instructions that is very silly. By the same criteria any RISC with fixed 32 bit instructions would have 4 billion of them.
My local university used to teach MIPS, and as of some years ago they’ve switched to RISC-V.
The final assignment at the time I took it was to write a program which compiles a subset of ARM machine code into RISC-V machine code, which was a challenging but so rewarding thing for a younger me to cut my teeth on.
It was a surprisingly modern class too. The in-class material was learning about pipelining, instruction/memory latency, and general CPU concepts, while the assignment and lab material was focused on writing RISC-V assembly and implementing more and more complex programs.
MIPS is great. You can learn it in great depth and fully understand the whole microprocessor while compacting it into a single class. You can make your own adder and multiplier with logic gates. It’s a scope that you can actually master
I agree. It's a shame that MIPS is mostly dead at this point.
(And a moment of silence for SPARC and OpenSPARC T1/T2 in particular - full 64-bit CPUs that were used in production.)
However, RISC-V shares most of the implementation benefits of MIPS, is unencumbered by IP issues, and seems to be steadily improving in terms of software and hardware support.
RISC-V has slightly more complicated instruction formats, but is otherwise feels a lot like a cleaned up and simplified MIPS.
The fact that you can easily see MIPS's 16 bit and (most of) 26 bit immediates in a hex editor is one low-key advantage (for teaching) that MIPS has over RISC-V.
But overall RISC-V is a much better teaching ISA. One great thing about is that there is a core version of the RISC-V spec that only has 47 instructions and essentially nothing else. There is no Memory Paging or Privileged Supervisor mode, and you can skip implementing proper exceptions to make the design even simpler.
We learned MIPS assembly as a small part of the computer architecture class at my university, in the first half of the 90s. It makes sense that RISC-V is the modern choice.
It's amazing how a lot of companies just forget how they got so big. If people can learn for cheap or at least very cheaply with your stuff, then they are going to use it when making money.
Restricting teaching with it or charging students the high corporate fees are just going to backfire in the long run. People will learn with whatever is cheap or free .
Davinci Resolve is getting more popular, because it's "free" and Adobe is a buggy piece of shit. Blender got popular, because learning at home, with any other software was way too expensive.
This is also how Linux became the server OS of choice for most companies, while Windows NT remained a niche product only found at a certain kind of company. And before that, easy availability of UNIX to students made it the default OS of any high-end computer throughout the 1980s and well into the 1990s.
Personally I like Niklaus Wirth's minimal RISC-5 (not to be confused with RISC-V). Wirth's systems were simple enough to understand from top to bottom, and RISC-5 was easy to emulate in software or on an FPGA (I also like Wirth's LoLa language.)
We used Sparc, PowerPC, and 68HC12 (or something in that family). They weren't x86, but they weren't obscure, either. What they all have in common is they instruction sets are small enough to be manageable.
We used 68HC11 for our operating system course and had to write a simple multitasking OS that ran on real hardware. I got to use that OS the next semester to run on a car that needed to follow a track, avoid collisions, and a few other things.
Being a microcontroller you got a bunch of things that today need full development boards right on the chip (ADC, RAM, etc).
When you first learn to fly to be a commercial pilot, why do you start flying silly single-engine cessnas or whatever, wny not hop straight into a 747 cockpit?
Because my professor hated the x86 architecture. At least I appreciated the honesty.
We looked at some popular RISC and CISC architectures, even looked at Itanium [1] as it was the hot new thing at the time. The professor didn't necessarily hate Intel, just the x86 architecture.
x86 should be taught as a follow-up course in the following semester as an example of how not to design a CPU architecture, specifically from the long term evolution perspective.
It would have been fine if x86 ceased to exist after 80486 or 80586, yet it has persevered and has continued to cause trouble with an incessant stream of extensions supplanting the previous generations, or expanding or «enhancing» them: MMX, then SSE (plus a further extension to the extension courtesy of amd64), SSE2, SSE3, SSSE3, then AVX, AVX2 and AVX512, and now AVX10 that is an overhaul of all previous extensions.
With a little bit of the design thinking and future proofing in mind, that hairy abominable mess could have been replaced with a single, scalable vector extension that would have not required a complete code rewrite over the next 30 years. Yet, MBA's over at Intel continued to milk the already ailing cow.
SVE didn't standardize a shuffle usable for processing strings without specializing your code to a specific vector width until October 2022, so it seems a bit unreasonable to expect Intel to have had it in 1997.
Shuffle is different, it is not a foundational SIMD instruction, it is actually a good example of an extension that can be added later as an add-on that does not require a complete code rewrite.
Whereas each of the MMX, SSE and AVX extensions was effectively a new instruction set, AND each had its own register set – 64, 128, 256 and 512 bit registers. Later generations (i.e. AVX2 and AVX-512) are better thought out, but, e.g. MMX – I do not think anyone uses it today, yet it is present in the silicon as the dead space.
Prior art existed long before – Cray had vector instructions first, so it is not like Intel had to invent them from scratch.
I could not use the Itanium server we had at work as it was reserved for the elite. I can say that my 32 bits single core P4 computer was not faster at number crunching.
As someone who was working on Itanium systems at the time, I can confidently say that "consumers" never had a chance to choose Itanium. It was only available on server hardware and Windows ... will there as a version for it but it was slow ... all the compatibility and performance downsides of M1 Macs, and more power hungry too... practically no upside.
It is still a common belief Intel created the Itanium to fool the proprietary unix vendors into thinking they can stop developing their own RISC CPU, but as soon as it happened, Intel gave up on Itanium as well. Solaris lasted a little bit longer only because Sun gave up early on Itanium.
I won't make the argument against variable-length vectors here, but I will note that, although some of the extensions you mention do change the vector length, for none of them is the vector length change the most interesting aspect; you could keep the vector length fixed, and they would all still be interesting. (The exception is avx10, but that is basically forwards-compatible and barely an 'extension', so.)
Contrariwise, although I think some of amd's choices in the initial design of amd64 have hurt its longevity—they could have made more breaks from 32-bit x86, although it is understandable why they didn't at the time—intel has been very careful and has done an extremely good job of playing the hand it's been dealt.
The culmination of my commmunity college's CS103 class was learning the ins and outs of an ISA called MARIE. only 8 instructions & an editor+simulator written as a java app.
I had a lot of fun spending most of my time in that class writing an entire development stack for that architecture: assembler, simulator, debugger, and eventually a very barebones forth!
Some architectures are better for pedagogy (learning) while still covering the important concepts. RISC-V or MIPS fit this well. RISC-V is also not patent encumbered so anyone can freely use it.
Some platforms are not great pedagogically, but are taught because they are used in industry, like x86.
ARM manages to be ok at both.
I don't see a point in learning with other architectures.
I think in my days one part of course was some imaginary set and one actual course was MIPS.
Still, picking something simple makes lot of sense as pedagogical tool. x86 is outright mess and ARM is probably going to that direction on long term as well. So something more locked down and fully explainable is the better choice. If students want to do assembly they then can pick what they need.
116 comments
[ 2.8 ms ] story [ 186 ms ] threadI actually think this was probably better than learning with real-world languages?
I believe it taught me to be a computer programmer. Not a Java guy or a C guy or a whatever guy. I think that was super valuable.
For assembly language we learned VAX assembly, which was already hilariously outdated, but again very valuable. It had a very beginner friendly instruction set, much more friendly than x86 which would have been the other realistic choice at the time.
Because Apple's M chips have not been on the market long enough for us to adjust, nor are there cheap versions we can pick up for our hardware labs.
Because phones are not good for teaching computer architecture. We want something with a large screen and keyboard.
If I were teaching computer architecture, I would use an ARM chip in a Raspberry Pi.
If I were, my students' first CPU would be something like a 6502 -- quite possibly God's perfect CPU architecture. Then move on to something more complicated, RISCy, and 32-bit.
I got a lot of mileage out of that class. The knowledge easily translates to other ISAs I’ve encountered in my career.
https://www.arl.wustl.edu/~jon.turner/cse/260/lec/washu2-1.p...
An introductory computer architecture course is generally starting from "here is what a transistor is" and hoping to end with "here is how basic computer games work" (e.g., nand2tetris). And has about 40 hours of instruction to do it.
Assembly is but a small part of the course. The ideal assembly language for such a course is one that is simple, something that you can let the interested student figure out how to implement it themselves with just a little bit of prompting. And frankly, most assembly languages aren't up to that task, even if you're willing to pretend that most of the ISA doesn't exist. x86 has issues with things like ModR/M or two-address instructions. ARM has things like r15-is-actually-the-program-counter-and-kinda-special. RISC-V coalesces most of the jump instructions into one or two instructions that is going to complete teaching subroutines in assembly (and also eschews condition codes).
At the end of the day, the stuff you're covering in introductory computer architecture is very far in almost every detail from how modern computers work, and it will take several courses on top of it to actually reach those details. The most important goal of such a course isn't to teach you how they work, it's to give you the information you need to understand the explanations of how they actually work.
Obscure CPUs have the same advantage. Plus with careful choice of architecture, or simply inventing your own, you make pedagogy much simpler because the architecture doesn't have all the complicated bits like branch predictors, register windows, speculative execution, etc. that modern CPUs have and you can focus on the basic, "must-have" components.
While I have seen many claims that the 8086 has more than 20 thousand instructions that is very silly. By the same criteria any RISC with fixed 32 bit instructions would have 4 billion of them.
The final assignment at the time I took it was to write a program which compiles a subset of ARM machine code into RISC-V machine code, which was a challenging but so rewarding thing for a younger me to cut my teeth on.
It was a surprisingly modern class too. The in-class material was learning about pipelining, instruction/memory latency, and general CPU concepts, while the assignment and lab material was focused on writing RISC-V assembly and implementing more and more complex programs.
This sounds like fun little project to learn risk v with. It's on my to do list with a million other things.
(And a moment of silence for SPARC and OpenSPARC T1/T2 in particular - full 64-bit CPUs that were used in production.)
However, RISC-V shares most of the implementation benefits of MIPS, is unencumbered by IP issues, and seems to be steadily improving in terms of software and hardware support.
The fact that you can easily see MIPS's 16 bit and (most of) 26 bit immediates in a hex editor is one low-key advantage (for teaching) that MIPS has over RISC-V.
But overall RISC-V is a much better teaching ISA. One great thing about is that there is a core version of the RISC-V spec that only has 47 instructions and essentially nothing else. There is no Memory Paging or Privileged Supervisor mode, and you can skip implementing proper exceptions to make the design even simpler.
The MIPS architecture was also sabotaged by IP issues.
As a result, architecture students are learning how to use and implement RISC-V. Thanks ARM.
Restricting teaching with it or charging students the high corporate fees are just going to backfire in the long run. People will learn with whatever is cheap or free .
Davinci Resolve is getting more popular, because it's "free" and Adobe is a buggy piece of shit. Blender got popular, because learning at home, with any other software was way too expensive.
https://people.inf.ethz.ch/wirth/ProjectOberon/RISC5.Update....
Being a microcontroller you got a bunch of things that today need full development boards right on the chip (ADC, RAM, etc).
And: http://visual6502.org/JSSim/index.html
(HN law mandates at least one 6502 post per week. Preferably more.)
And lest we forget (not 6502, not commercial, but some TTL): https://www.homebrewcpuring.org/ringhome.html
We looked at some popular RISC and CISC architectures, even looked at Itanium [1] as it was the hot new thing at the time. The professor didn't necessarily hate Intel, just the x86 architecture.
[1] https://en.wikipedia.org/wiki/Itanium
It would have been fine if x86 ceased to exist after 80486 or 80586, yet it has persevered and has continued to cause trouble with an incessant stream of extensions supplanting the previous generations, or expanding or «enhancing» them: MMX, then SSE (plus a further extension to the extension courtesy of amd64), SSE2, SSE3, SSSE3, then AVX, AVX2 and AVX512, and now AVX10 that is an overhaul of all previous extensions.
With a little bit of the design thinking and future proofing in mind, that hairy abominable mess could have been replaced with a single, scalable vector extension that would have not required a complete code rewrite over the next 30 years. Yet, MBA's over at Intel continued to milk the already ailing cow.
Whereas each of the MMX, SSE and AVX extensions was effectively a new instruction set, AND each had its own register set – 64, 128, 256 and 512 bit registers. Later generations (i.e. AVX2 and AVX-512) are better thought out, but, e.g. MMX – I do not think anyone uses it today, yet it is present in the silicon as the dead space.
Prior art existed long before – Cray had vector instructions first, so it is not like Intel had to invent them from scratch.
It is still a common belief Intel created the Itanium to fool the proprietary unix vendors into thinking they can stop developing their own RISC CPU, but as soon as it happened, Intel gave up on Itanium as well. Solaris lasted a little bit longer only because Sun gave up early on Itanium.
Contrariwise, although I think some of amd's choices in the initial design of amd64 have hurt its longevity—they could have made more breaks from 32-bit x86, although it is understandable why they didn't at the time—intel has been very careful and has done an extremely good job of playing the hand it's been dealt.
I had a lot of fun spending most of my time in that class writing an entire development stack for that architecture: assembler, simulator, debugger, and eventually a very barebones forth!
Some platforms are not great pedagogically, but are taught because they are used in industry, like x86.
ARM manages to be ok at both.
I don't see a point in learning with other architectures.
At just 40 instructions, it is well-suited for education.
Still, picking something simple makes lot of sense as pedagogical tool. x86 is outright mess and ARM is probably going to that direction on long term as well. So something more locked down and fully explainable is the better choice. If students want to do assembly they then can pick what they need.