Best/Worst Assembly Language Instruction Set

I have been reading up on it lately to get some knowledge on it. I was thinking about learning it first to try to put together something on the Genesis/Megadrive. I had considered going the C route but from what I was the Genesis and C stuff seemed to have bugs and also seemed like it over complicated things.

 

C makes some things easier, but ASM is the way to go IMO, and its not tough at all. when you're going to make extensive use of the SWAP instruction, then things become a bit confusing when there's a lot of code ;P

 

I've programmed pretty much every processor at the assembly level and even to this day, I find it refreshing. 68K was probably the easiest to pick up, and the PDP-10 was the most powerful (you could set up arbitrary bit field pointers with one register into another). VDP0/1 on the PS2 was also pretty nice from a vector processor standpoint, though it was missing a lot of functionality.

The past few months I've been doing a lot of work again with the 6507 (a 6502 with less address lines) and it is still one of my favorite CPUs to write assembly for.
--Selgus

​

 

how insightful, please tell us more about yourself

 

Speaking of 32bit MIPS and this being a console forum at heart, I m surprised no one has mentioned the RCP (or doubt that many have attempted to code it). It might be the lack of documentation to blame but coding a processor is one thing, hence handling assembly, but you have to take the system as a whole, at least when dealing with embedded stuff like most consoles of old. Everyone and their mother can probably code an R4000 series RISC but working with the R4300i and having to deal with the RCP every time is another matter, without even getting into memory latency issues. I m not big on coding anyway so take my view as you may.

 

I'll pitch in my two cents, I've done programming or at least played a little with with i386 (protected and long mode), m68k/coldfire, ARM, AVR, alpha, ia64, sparc, powerpc, and a few others I probably forgot. Most of my experience is either i386 or AVR with ARM coming up behind:

Favorite overall: DEC Alpha
- its a streamlined instruction set that was just beautifully done. One instruction that required privileged access, and sane 64-bit operations (no long mode fun :-/)

Favorite I heavy programming in: AVR Amtel 8
- Simple instruction set, well documented. Its similar to ARM, but with a full set of integer math instructions if memory serves, and amazing code destiny. The only weakness compared to ARM is that it can't branch on every instruction.

Not bad: ARMv5 Instruction Set
- RISC architecture, simple, clean memory model, but lacks some useful math instructions which you take for granted on other architectures like hardware multiply.

Not Bad: PowerPC
- One of the few true biendian architectures in existance (arm and mips both support little and big endian mode, but its not something that can be switched in userland; powerpc can do both in most versions of the processors). While technically a RISC process its more CISC with a LOT of instructions

Most mindwrapping: Intel Itanium
- Meet the architecture that can actually execute more than one instruction per cycle. You specify up to three(?) opcodes into a bundle, and then the processor can execute them in a single go in most cases. While interesting in paper, this leads to incredible poor code quality since if you can't parallize the instructions, you have to set the other two bits of the bundle to NOP. Part of the reason compilers are near impossible to write for ia64 is the insanity of its instruction set.

I'll post more when I'm more awake, but I figure I should leave my mark on this thread
Fun side note: my current desktop is an ia64.

 

And for arcade hardware like Nec V60\70 systems ?

 

I wish that Transmeta would expose the 'code-morphing' layer of their processor. It could be ab excellent CPU for hand-held consoles but not the way it is now.

 

I like x86, PowerPC is ok, kinda gross..

 

68000 and Arm are awesome. Arm is amazingly powerful. 68000 is actually fun to program on.

65816 is horrible. HuC6280 can't be far behind. The HuC6280 feels like a hacked on extension of the 6502, it seems better done than the 65816 though.

x86 is pretty bad, especially with it's limited registers. The x64 stuff looks like a step in the right direction, only 30 year too late.

PowerPC was my first exposure to Risc, and I never really caught on, until learning the Arm processor.

8080/z80 were ok, nothing incredible. By the time I started using these I was already using 68000.

Maybe that explains why I've always had a harder time using the 65816. Having to account for being in 8 or 16 bit mode seems to complicate the entire process.

Yes, the 68000 just feels right. I think it is the top of the heap in CISC chips. Data and register sizes were handled with a simple .b .w .l; which I still have a hard time separating from today. Hearing the term word (32 bits in Arm-land), always makes me think 16 bit. The instruction set was well layed out, and a departure from the 3 letter mnemonics of older chips. And, the order of the registers made sense (same with Arm). It almost feels like a language; your having a nice friendly chat, over tea, with the processor. :icon_bigg

In asm, you will be working at a very low level. C hides a lot of 'stuff' from you. For example:
'Variable++;' takes care of the size for you, in asm you have to consider the size always, and can't simply do an 'inc Variable' (addq #1, d0). This is a very common bug, for me.

 

The 68000 has got to be one of the easiest processors ever to code assembly on. Dead easy. It's like you don't even have to try. I'm not kidding <_<; It's no wonder why it was so popular.

Optimizing code on the 68000 is kinda neat. Most of the time you're comparing all the different addressing modes and figuring out how many cycles the damn instructions take (adding the base instruction time to the source/destination addressing mode). There's just so many possibilities though. But it doesn't have the same thrill as optimizing on 65x processors. 65x gets pretty complicated and abstract for optimizations. Which is an extension of the processor itself - haha. Splitting arrays for high/low offsets, offseting index regs and base address to take advantage of Z flag roll over, tiny LUTs everywhere, lots of self modifying code, etc <_<;

HuC6280 is just a custom R65CS02. Everything that the 'C02 added over the 6502 (which is in all the important places IMO) plus what Rockwell decided to add as well (which WDC later adopted) and then Hudson threw in some special opcodes. Going back to the original 6502 after working with anything 'C02/'CS02/'6280, is harsh and a pain.

Besides some of the slow execution time for some addressing modes on the 68000, the one thing that really bugs me is the lack of a decently fast indexing mode. Indexing on the original 68000 pretty much isn't worth it. I simply just keep a base address in ram and sum it, and the indexing starting point value, into an address register. It's not a big deal, but still it irks me. Of all the addressing modes, (An,Dn) with or without post increment - should be the same cycle time as (An). It's my 65x LUT driven background/experience, I guess. Did they fix this on newer revisions of the chip (020, 030, etc)?

Coming from 4 years of cutting my teeth on *65x, it's not a big deal to write crazy abstract/optimized code. I can imagine though, someone coming from a 68k background and looking at the 65x and thinking....WTF!???

 

68000 - loved it.
ARM - loved it - but more complexity that 68000 and more scope for clever optimizations.
80x86 - not so much fun.
6502a - OK - real basic though.

 

PowerPC - great
MIPS - pretty good (delay slots .. meh)
x86 - instructions for so much, but more registers kthx

 

I'm so late to this topic.

To date (as of posting) i've worked in Arm7/Arm9, Mips (4xxx) & PPC (Cell).

I'm 100% bias on my pick but my favorite so far is mips but a lot of that has to do with me working with it for so long. I'm slowly starting to warm up to writing for the Cell (not so much the PPC instructions but purely the chip design).

 

ARM!, by far the most friendly assembler I've used. Sophie Wilson herself said it was decended from 6502 set in the aspect of making the assembler as easy for a person to use as possible and it's the only processor I know of which does A=B <operator> C style syntax, plus conditional instructions.

x86 is okay, but lack of registers causing the push/pop dance, divide by zero handling and probably a list of other annoyances make it a little bit of a chore to do stuff in. But then again, I do program the CPU like it's a RISC CPU (I know I know, internally parts of it are essentially), I just try to avoid complex instructions.

been wanting to tamper with the SH4 processor and maybe the PPC processor, just to see what coding for them is like. but it's a bit awkward with only standard consoles with those chips in :/

 

M68000 - Best one in existence
80x86 - Most prominent one in existence...not as good as M68000 though
Z80 - Good as a sub-CPU
6502 - Hate it like the devil
MIPS - Ehh...so-so
PowerPC - Haven't really tried it
ARM - Ditto
65816 - Ditto

 

I don't know why all the 68K love... Too many underused/redundant instructions, too many addressing modes, too much microcoding, crazy slow interrupts! I'm a believer in MCU-grade RISC, for me the ideal CPU would have few registers, up to 32 instructions, a parallel multiplier/divider, and a couple addressing modes (one programmable for indexing would be cool). One way to do something well is enough!

 

Maybe it's just me, but I find Assembler to be a bit too mind-blowing for me. I'd rather keep my sanity. (^_^);

 

ASM isn't that bad. But then again I've only messed with 6502, 65816, and Z80-like ASM. High level languages like C are easier to manage things but you can live without them on simpler systems.

 

Yeah, C/C++ are great for the modern world of fast computers and such, but for old stuff, it just didn't have the space to store any kind of C library on the console, and furthermore, if one were to code in C with raw addressing and such, they might as well do it in assembly and cut down on the useless code generated by the compiler.