ALPP 01-14 -- Doing This with Other Processors

Doing This
with Other Processors

(Title Page/Index)

 

This is kind of a non-sequitur from the debugging riddle session we (probably) just finished, but you might be wondering about approaching other CPUs the way I'm approaching these four.

I've mentioned that I'd like to do this kind of introduction for other processors, showing how the various introductory concepts map to the 6502, 6805/68CH08, 8080/8085, Z-80, 1802, 9900, Z-8000, 68HC11, 68HC12, 65c816 (in both run-time modes), 68HC16, ATMEL AVR (several models), 8086, 80386, 88000, ARM (several models), AMD64 (several models), PPC (several models), MIPS, RISCV, ...

Of course, there's no way I'm going to have enough time to do all of that. Maybe one or two. But if I were to do any, I would need a couple of things:

• a libre/open source emulator,
• a libre/open source debugging environment,
• a libre/open source assembler,
• manuals that I can refer to without licensing terms,
• time to install and learn the tools. 

A couple turns into five, doesn't it?

MAME might do the job for the emulator/debugger for a number of CPUs, especially now that they've made the debugging environment a priority. But it does take a lot of space on the persistent store -- alleviated in part by the capacity of modern "flash" memory devices.

Time, though, is the killer.

I'm getting old, and I still have to pay rent and buy food for the family. 

I may be able to get back to write chapters for, say, the 8080 or the 6502. Or the 65C16 running in 16-bit mode. Or the 8086.  (Z-80? Meh.)

Or the ARM in 32-bit and 64-bit modes. I'd be willing to do the 32-bit mode now if I could find a decent libre/open source emulator, debugger, and assembler, or if I could talk myself into springing for a Raspberry Pi class computing box. Doing this on a Pi using the Debian/Linux OS tools would be something of a twist, but wouldn't be too twisted.

Could you do it for yourself?

Work through a unit for the four I'm presenting, then stop and read the manuals for your processor of interest and go back through the each set of chapters, implementing the corresponding code for that processor?

Sure. I think so. 

As long as you don't copy my code or my explanations, you could even blog about your work and link to my work. And if you contact me, I might be able to check what you've done and possibly link back.

You can comment here, of course. I do check for comments, every now and then.

If you find my on eXTwitter, it probably won't do much good to try to contact me there, for the present. They seem to have a disagreement with me, and I can't seem to find a reason to care. 

On FaceBook -- I'm not sure why I have more patience for Facebook than for eXTwitter, but my writing group is xhilr. I also hang around in the Motorola 68000 Programming group, the Motorola 6809/6800 group, the vintage computer/microprocessor group, the minimalist computing group, and several related groups.

Things that you might want to look at as you approach another processor --

Does your processor have a single accumulator where all the math gets done, or does it have multiple registers where you can do math?

Does it have an index register? Is it wide enough to address all of memory? (There is a way to use self-modifying code to get around not having an index register, but it's tedious and easy to break.) 

Or can the general-purpose registers serve as indexes? That's very common in RISC designs. It's also true or partially true in some CISC CPUs. In the case of the 8080, one register pair, HL, can serve as both a pseudo-accumulator and a general index register.

Speaking of the 8080, do the registers seem to have specific purposes -- certain instructions that you can only use with a specified register?

Can you specify an offset to an index as part of an instruction, or do you have to use more instructions to add the offset to the index register?

If it doesn't have a lot of registers, does it have a short addressing mode that helps with allocating pseudo-registers in memory? That's the case with the 6800 and 6502. The 6502 even allows you to use such pseudo-registers directly as 16-bit indexes, which is what essentially makes the 6502 a reasonably powerful processor.

Is there a stack register? How many? Will you have to synthesize one or both stacks in software? That's actually the case with most RISC CPUs, although there is usually at least a recommendation for which register to use as the return stack pointer.

There's more to consider, but this is probably sufficient to get you started, if you want to use this tutorial as a guide to study other CPUs.

And thinking about the above might even help as we move on to character and string output functions.

(Title Page/Index)