IMHO, the difficult bit with assembly language is that you have to keep track of all the "book keeping" needed by your algorithm. If you need 10 variables, and array of 100 integers, and pointers to subroutines, then you have to keep track of all this stuff yourself. This means that you have to start planning on paper long before you write your first opcode. Of course, it also means that you have to be familiar with the machine architecture, how many registers it has, how much stack, etc, so that you can figure out WHERE you are going to store all the stuff you need. In comparison, with a high level language, one can just declare a bunch of variables and an array, and the compiler does all the book keeping for you. It's still advisable to make a plan before you start coding, but you don't have to know the addressing modes of the CPU, etc. So, my suggestion for learning assembler would be: run through some tutorials to learn the machine architecture and what operations the CPU is capable of. (Can it do indirect jumps? relative jumps? indexed addressing of storage?) Once you sort of have a grasp of machine architecture and the instruction set, set yourself a problem to solve, and try to plan out how you'd attack it ON PAPER (or virtual paper, in a text file.) I would write my plan down as comment lines in a text file, and then when it was time to code, code up each section between the comment lines. I was an embedded developer for many years. Initially, I wrote everything in Z80 assembler. Later, when compilers (and cross compilers) became readily available, I would code in C, and then hand optimize the assembler output of the C compiler for the nasty bits that had to run extra fast. I never got particularly good at X86 assembler, but I learned enough to be able to hack the compiler output so my application would run faster. Just for the hell of it: here are two articles I had published "back in the day": This first one is about hacking the CPM command processor so that it has Emacs-style command history. This work was all in Z80 assembler, running on an 64180 with banked memory available for the history storage: http://www.dudley.nu/MicroSystemsJournal_article_198609.pdf This second article was the cover story in the August 1990 Dr Dobb's Journal, about converting a "real mode" X86 application to run in "protected mode". The application was a electronics CAD package, written in C, and the protected mode code was a fair amount of 386 assembler: http://www.casano.com/ddj_0890.html Bill Dudley This email is free of malware because I run Linux. On Wed, Jan 18, 2017 at 8:24 AM, Neil Cherry via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On 01/17/2017 11:17 PM, Evan Koblentz via vcf-midatlantic wrote:
I decided to try to cookbook series. Getting it now...
Or: Don L. was trying to sell more books. Very next sentence on that page:
"There is a series of nine discovery modules in Volume II of Don Lancaster's Micro Cookbook..."
I love Don Lancaster's stuff! I've not read all of it but I do recall learning how to do reverse engineering with Don Lancaster's Cookbook (? not sure if it was part of the series). Remember that I had an Atari 800xl and he was referencing the Apple ][ series. If anyone has seen my little red notebook with the Apple sticker on it, that's my notes from when I was reading the series (when Don first printed these books). I used the Omnimon XL instead of the Apple Monitor. As far as assembly language books go, I love the books of Lance Levanthal.
Having said all of that, computer languages come pretty easy to me. I have had trouble with Intel's memory access (far, near, argh!) and the PIC chips memory layout (banked memory).
-- Linux Home Automation Neil Cherry ncherry@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies