Easy 6502 by Nick Morgan.
From the post:
In this tiny ebook I’m going to show you how to get started writing 6502 assembly language. The 6502 processor was massive in the seventies and eighties, powering famous computers like the BBC Micro, Atari 2600, Commodore 64, Apple II, and the Nintendo Entertainment System. Bender in Futurama has a 6502 processor for a brain. Even the Terminator was programmed in
6502.So, why would you want to learn 6502? It’s a dead language isn’t it? Well, so’s Latin. And they still teach that. Q.E.D.
(Actually, I’ve been reliably informed that 6502 processors are still being produced by Western Design Center, so clearly 6502 isn’t a dead language! Who knew?)
Seriously though, I think it’s valuable to have an understanding of assembly language. Assembly language is the lowest level of abstraction in computers – the point at which the code is still readable. Assembly language translates directly to the bytes that are executed by your computer’s processor. If you understand how it works, you’ve basically become a computer magician.
Then why 6502? Why not a useful assembly language, like x86? Well, I don’t think learning x86 is useful. I don’t think you’ll ever have to write assembly language in your day job – this is purely an academic exercise, something to expand your mind and your thinking. 6502 was originally written in a different age, a time when the majority of developers were writing assembly directly, rather than in these new-fangled high-level programming languages. So, it was designed to be written by humans. More modern assembly languages are meant to written by compilers, so let’s leave it to them. Plus, 6502 is fun. Nobody ever called x86 fun.
I’m not too sure about no assembly language in your day job. The security on Intel’s Ivy Bridge line of microprocessors can be broken by changing doping on the chip. Not an everyday skill. See, Researchers can slip an undetectable trojan into Intel’s Ivy Bridge CPUs by Dan Goodin for the details.
I mention the 6502 ebook because programming where subject identity is an issue is different from programming where all identities are opaque.
Think about calling a method on a class in Java. Either the runtime finds the class and method or fails. It does not look for a class with particular characteristics and if it passes a subject identity test, then invoke the method.
I mention this because it seems relevant to the scaling question for topic maps. When you are manipulating subject identities, there is more work going on than invoking opaque strings that are found or not.
Part of deciding how to deal with the additional overhead is choosing which subjects are treated as having identifiers and which are going to be treated as opaque strings.