Introduction to Computer Organization: ARM Assembly Language on the Raspberry Pi
bob.cs.sonoma.edu
bob.cs.sonoma.edu
- They teach the concept of a computer program as a bunch of single small logical 'steps'.
- They make it easier to keep new students interested without plying them with pages and pages of 'magic code' - not only can you make a zero-dependencies program (in the case of simple mobile chips), your 'hello world' is actually in the physical world. An LED, a motor, what-have-you.
- The core instruction set for a Cortex-M0+ processor has what, 60 instructions? It's not very complicated.
On the con side of things, the whole idea of registers controlling hardware peripherals can be a little weird, and you have to get people comfortable with command-line debugging utilities. The concepts are simple, but GDB isn't. And many of the available IDEs aren't very cross-platform.
And I guess application processors also probably introduce their own extra complexities, compared to a Cortex-M line which is more comparable to an Arduino than a RasPi or Chromebook. But hey, there's also less hardware available with the sort of support that a Raspberry Pi has; the closest you'd probably get is a cheap generic $3-5 STM32F103C8 dev board.
If anyone else is interested in this sort of thing, the reference manuals provided by ARM are also very readable, for example: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0484c/DD...
Maybe someday the lowrisc project will become a reality, and they can use that, and teach RISC-V instead.
Basically it's an embedded programming class where the teacher decided to write the manual and publish it as a book, so don't read too much into the platform they targeted beyond that. But the book we had was quite good if I recall (I might have it packed away somewhere in the garage), so I expect this one might be good as well.
As an aside, from looking at the linked author info, I'm happy Plantz finally got the chance to retire in 2004. He's a great teacher, but he was planning to retire before 2000 IIRC, and kept putting it off because of staffing issues, and then California university budget cuts and hiring freezes making getting good (actually, any non-temp) teachers hard. I'm sure he has a few happy cats, and if you ever run into him, he's got a few space program stories from the past to share. :)
EDIT: looking a little deeper into this website, it looks like a better resource than any other thing I've found.
Note that under the hood "mov Xd, Xm" is a convenience alias for "orr Xd, XZR, Xm" -- the CPU itself will only see the logical-or, but the assembler and disassembler will understand the 'mov' syntax and should convert each way automatically. This is documented in the v8M ARM ARM in the "MOV (register)" instruction description. Perhaps whatever assembler you're using hasn't implemented that convenience syntax, but all the common ones (including the GNU assembler and LLVM assembler) should do, so it's surprising to encounter one that doesn't.
Current CS student and in our architecture course we were learning surface-level x86 but mostly Y86, which is a toy language simplification of the x86 architecture. No real complaints about it, but friends of mine in electrical and electrical computer engineering (different school at my university) were learning ARM. Not only was it simpler it was much easier for them to implement non-virtualized code.
I thought the engineering department was doing it better.
+1 to GDB not being simple, was a larger learning curve for most of our class than C, x86, or any of the concepts.
It went really well - although there are always rough edges the first time through a course. Next year, I'm going to tighten things up (one of my jobs over the southern summer before the course runs again in Feb 2018).
Happy to answer any questions that folks have.
Although as I said, there are certainly some things I'll tweak next year, having been through it once. I'm under no illusions about it being perfect :)
Will for sure go through the materials. If you ever come to sweden, let me buy you a beer!
That said, I think the AVR ATTiny and ATMega chips easily fit the bill, and possibly better. From a teaching perspective, they meet all of what you're talking about, and IMO they're better for simple circuits like flipping LEDs because they can really work with basically no extra components - you can just plug it into a breadboard like any other simple chip.
https://github.com/PeterLemon/RaspberryPi
https://hackaday.com/2014/06/23/programming-pi-games-with-ba...
Anyone wanting more, the MIT Computational Structures courses are always available via EDX:
https://www.edx.org/course/computation-structures-3-computer...
I hear stories about the 'good old days' when everyone was hacking on some amazing open hardware and earning their chops knee deep in assembler etc etc.
This kind of feels like I might get a little taste of that by following this book.
Awesome!
PS - Is there a hardcopy or pdf available too?
As a security person, I have just one request - in 2.9 you explain/recall how functions look in C, then you explain printf, then the first C statement you execute is
printf("Enter an unsigned decimal integer: ");
Please, please can this kind of thing be printf("%s", "Enter an unsigned decimal integer: ");
I know this string is a compile-time constant, so it's not going to hurt anyone, but you're teaching people the old myth that printf(string) is the way to print a string and at some point they'll try this with a user-supplied string.
In my opinion, a printf with only one argument is always a code smell.
EDIT: also, the solutions to exercises 1 and 2 in 2.16 are vulnerable to buffer overflows.
I am also very security-conscious in my programming, but the rule that I apply is
printf(string);
printf("%s", string);
> In my opinion, a printf with only one argument is always a code smell.
as cargo-cult coding.
"Code smell" to me means code that should make you feel bad when reading/writing it, as opposed to code that's wrong - a psychological device to make code that often is wrong, always look wrong. The classic example is if(a = b) which is sometimes really what you want - but I'd write this if((a = b)) in this case to make it clear it's deliberate. printf("%s", str) is the same kind of thing, and it means when I'm reviewing code I don't have to go and check whether str really is a compile-time constant or not. Better still, it's also a sign to the human reader that there's no fancy formatting going on here - you're really just printing a string.
"Always use 2+ arguments to printf" is a rule for humans that has the advantage of being really easy to follow and to teach and avoids the most common version of the vulnerability. I don't mind people who know what they're doing breaking this rule (sometimes breaking a rule when you know it's ok is pretty much a definition of being an expert) but I do include the rule whenever I'm teaching printf to beginners.
`printf` gives the caller more opportunities to accidentally cause bugs. The difference in LOC when comparing for example FreeBSD `puts` to `printf` variants is so great that if you had any reason to doubt the implementation of the standard library you would be better off writing your own formatting functions and print everything with puts/putc because that would likely be easier to test and verify than identifying all the edge cases in `printf` flag parsing.
Personally, I think either way to do it is fine, but since we're seemingly all in the mood to be picky about code smell, security and such, I thought I'd join in. In reality the examples mentioned are not production code, and they are likely to be used with GNU libc, not Cheap Chip Factory libc 0.0.1 alpha. In most cases, the standard library is well exercised because its use is ubiquitous. If that can not be assumed, and you're somehow stuck with a broken standard library, I'd rather go ahead and verify puts, and let you dig into the `vsprintf` parser and make sure it works in all the cases it gives the caller an opportunity to create :)
To me it also includes:
- forbid patterns that are perfectly fine (as in this example), but we nevertheless forbid them for a fear of wrath of a demon, eh, I mean for the fear that it might introduce some bug (without giving a very good reasoning).
- using "best practises" (in particular "best security practises") that are either not based on strong evidence, but on some obscure oral tradition/scripture that says this is the way to go.
Using puts() will give you a terminating line feed though, which might not be what you want for a prompt. On the other hand that likely saves you from having to deal with output-flushing and so on ... Might be nice for teaching.
Its a lovely book, but its hard to get hold of MIPS processors these days. Hopefully this creates a new generation of devs which can tinker with real hardware and are armed with proper education behind how it all works.
Super happy, wish I had this during mys schooling. :)