5 ms·
How do the 6809 features compare to ARM and RISC-V? If someone wanted to play with assembly, would it be nicer on contemporary computers, or is there something
by ilaksh 6y ago
How do the 6809 features compare to ARM and RISC-V? If someone wanted to play with assembly, would it be nicer on contemporary computers, or is there something about 6809 that is still an advantage? Maybe now just the simplicity could be helpful?
- jacquesm 6y agoThe 6809 compares to ARM and RISC-V the way a bicycle does to a Greyhound bus.
- colanderman 6y agoARM32? I would disagree. I've had occasion to do reverse engineering and hand-assembly of various bits of ARM32 Thumb code recently. It brought back all the feels of hand-assembling 6502 on my Apple //e in 1994. Moreso even than AVR assembly. The ARM32, 6809, and 6502 are all cut from the same cloth. Same type of vehicle, just more cylinders. ARM64 and RISC-V I would agree are very different beasts. One of the key differences I feel, is that caching and pipelining become much more important on these systems. Most (not all) ARM32 systems have very simple and short pipelines, and no cache. E.g. Cortex-M3 and -M4.
- colanderman 6y agoARM32 has the same "feel" to me as the 6502 and 6809 do. If you wanted to have a similar experience as those of us who cut our teeth on those systems, but on a more modern platform, I think you'd get it from ARM32. Really the most noticeable differences are, you won't have to waste cycles (literally) writing out 16- and 32-bit arithmetic carry code all the time, and you get registers instead of the zero-page. (Though the experience of writing carry code is still there, if you want to do any 64-bit arithmetic.) The historical reason for this is that ARM32 was directly modeled after the 6502, which in turn was based on the 6800, as was the 6809.
- jhallenworld 6y agoAlso: 6809 has PSH and PUL that take a register list. ARM's LDM/STM is a direct copy of this feature (via 68000's MOVEM). Other RISC processors did not have a list. The conditional branch instructions (and set of flags) for all of these are from the PDP-11.
- colanderman 6y agoOff topic -- thanks for your work writing and maintaining JOE. (Assuming you are that same jhallen.) Been my primary editor for about 20 years now.
- ddingus 6y agoI am curious to read other opinions. That said, simplicity has two axis: The instruction set and overall CPU complexity, and the hardware it's running on. In my view, playing with assembly is best done while also either playing with hardware, or really understanding and having access to said hardware at the "raw metal" level. The distinction being computation, and that's not too much different of an experience, and making things actually happen, which can be a widely different experience! The simplicity, again in my view, of 8 bit type hardware is very helpful. It's not so large and or complex. People can understand it reasonably well, and with some degree of effort, make things happen. Back when I was learning assembly language, it was on these kinds of systems. Sometimes the hardware played a lesser role, say a machine that has serial i/o for use with a terminal. Other times, the hardware was far more prominent, like with home computers of the time. With the terminal, one would typically setup the hardware for serial comms, and once that was all done, basically stuff values, from a buffer, into the designated address or capture them, into a buffer, as they arrived. On a machine with built in display, the display was typically memory mapped in some fashion. Writing to a specific address in RAM would cause a character to appear on the display screen. It was common to have a memory map of the computer handy when writing assembly language programs. Put a number here, or set a bit there, and things would happen, like maybe click a speaker, or change the color of the screen, turn a motor on, or make a sound. Have you looked at the 6502 hardware tutorial kits Ben Eater is doing? https://eater.net/6502 https://eater.net/6502 (I mentioned up thread the idea of doing these with the 6809, which is tempting me badly right now...) They are fantastic! Assembly language + hardware functionality = your program. And this is the embedded view on things too. Having everything simple and small generally means being able to make good progress and learn a lot without it being too heavy of a lift. And depending on what your interests are, frankly you might be able to do more than you would expect. Should your interests lie in this direction, a 6809 is an awful lot of fun to program. It's one of the best 8 bit experiences, IMHO. Be warned though! It can be an addiction, and once it starts... you may find yourself with a scope, spiffy new tools, and the need for some space to work, and, and, and! Mine has been life long, first triggered by writing a line of BASIC, pressing carriage return (enter key these days), and seeing a light bulb turn on. :D Soon after that, it was a speaker click, then a loop to make sounds, then one with parameters to make different sounds, and, and, and... There you go. But, it's not necessary to fixate on this chip either. It's a beautiful CPU, no doubt. But others are also fun, and they have their advantages and there is a wide variety of hardware out there to program in and with. If this kind of thing does not appeal in some way, then yes! By all means explore assembly language on something newer, bigger and faster. Or, maybe it is, and or you don't know. I would suggest emulation. We've got pretty great emulation for all the old machines. Many of us, who enjoy these older CPUs, work with emulators, because we've got access to modern tools and such that make life a whole lot easier. While there is something to be said for an authentic experience, to be frank? It's a lot of work, and kind of painful most of the time. A good emulation smooths away a lot of pain points and "nicer" is a lot less important. Use an older CPU, newer one, freely. And you can save states and all the other good stuff that makes learning less painful and more fun and fruitful. Right now I've got a little 6502 project in progress for an Apple //e type computer. It's being done in an emulator, and from time to time I move it all onto the real computer just to see it all go and interact with it for real, and or check it out at different clock speeds, or just show off. But the majority of the time developing is on emulation. I can fire it up, make a little progress, or explore an idea, and then save everything for the next step later. In this way, it's easy to jump in for an hour, have some fun, and get back out again when that hour isn't costly in some way. Probably more here than you wanted. Hope it helps.