Assembly Language

Started by
18 comments, last by Cherez 19 years, 4 months ago
I recently started learning assembly language for my calc, but I'd really like to try it on the computer. But I may have some wrong ideas that I'd either like to correct, or make sure they're really wrong: 1) Does every CPU have a seperate assembly language? I got this idea from the fact that the assembly language for my calc is "z80", and I think the CPU goes by the same name. Would that mean that what I write on my Intel machine wouldn't work on someone's AMD machine? 2) Are all assembly languages somewhat similar? Do they all have pretty much the same idea, with jumps, calls, and working up close and personal with individual bits and bytes?
.:<<-v0d[KA]->>:.
Advertisement
1) Mostly but AMD and Intel PCs should be the same, since the run the same software.

2) Yes, on the surface all assembly languages look the same but they are different as far as different machines do things differently from one another.
Assembly language for Pentium and Itanium (both Intel) is different, since they got different registers.
AMD and Intel can't run the same programs if you compile your application with Intel-specific instructions. In fact, I had a commercial game fail on me because I had Cyrix CPU. That game was Might and Magic 6, I believe, and the company had to issue a patch for non-Intel CPUs.

In fact if you optimize for Pentium 4, you probably won't be able to run on Pentium 3, because they likely added registers.

But all those cases are extreme (except for Pentium and Itanium, they really have a separate Assembly language), because they involve optimizations, which you don't need to use.

If you want your program to be cross-platform, you can't use assembly, because its completely different on Unix platforms.

http://www.mildspring.com - developing android games

To answer your first question, you need to write different assembly for each TYPE of processor. So the same generic code will compile on both intel and AMD x86 processors, like the pentium or athlon (although each company added their own features too, which you could take advantage of at the cost of losing compatability for the other), but not on say, an AMD64 or an ARM. And your calculator assembly code probably wont work on either, unless it was heavily modelled after them.
To the second query, YES. The foundations of computer science don't evolve as quickly as the higher level stuff, and pretty much any system you write assembly for will have registers, a stack, and a heap, as well as instructions like mov, add, jump and all the rest. As stated above though, many processors will also have their own specialized functions - creating truly optimized machine code for a specific processor will almost certainly require reading up on these.
One other thing. There is one area in games where assembly code is currently on the cutting edge - writing shader code for programmable GPU's. So if you have any interest in writing assembly and working in a fresh new area of game programming at the same time, you might consider getting into shader stuff.
1)
You may be able to find a "Cross-Assembler" for Z80 to x86 (a cross assembler generates byte-codes for one platform from the assembly languge of another platform). In general though, you'd be better off rewriting the assembly language yourself.

2)
There are 2 schools of thought on chip design (and thus on assembly language programming). Chips are generally either CISC (complex instruction set chips) or RISC (reduced instruction set). x86 chips are CISC, and have 200+ instructions. ARM and PowerPCs are RISC chips, and have 50+ instructinos. CISC instructions generally take longer to execute, but fewer of them are needed. RISC instructions execute more quickly, but it takes more of them to do the same job. People argue that CISC or RISC is better, but it really doesn't make a difference (flame sheild up).
Hmm... aren't all programs made out of assembly language? When you ship an executable, isn't the program in assembly language format? Wouldn't that mean that I have the same restrictions in C++ as I do with assembly? Am I totally getting the wrong idea [smile]?

Also, what exactly should I learn then? What is the name of the most generic, cross-platform (or otherwise good) assembly language?
.:<<-v0d[KA]->>:.
Commercial software is machine instructions. Assembly language is not written quite the same (though conceptually it is mostly the same). That is why if you write in assembly language, you still need to use an assembler to translate into machine code.
When you write in C or C++ it is translated by the compiler into assembly language and then assembled into machine code by an assembler, there for C/C++ is definitively no more expressive than assembly language.
Hmm... so if I avoid certain commands, I can go cross-platform?

What's the name of the assembly language?
.:<<-v0d[KA]->>:.
Not really. I think you'll find that many fundamental opertations are machine specific, though in high-level languages this fact is hidden. When you compile C/C++ there is a different version of the compiler on each machine that produces different assembly language. If you want to write cross-platform software, you'll need to use a high-level language.
AMD and Intel CPU's are both based on the 80x86 architecture, which means they both share a base set of instructions. However, each vendor adds specific 'extra' instructions - e.g. 3DNow!, MMX, etc. to their CPU's.

Regarding compilers, a quick glance at the available compiler settings in VS.NET gives me optimisations for Pentium, P-Pro PII & PIII, or P4 and above. I can also 'Enable Enhanced Instruction Set' for SSE or SSE2. Hmmm.

But yeah, all assembly languages follow the same patterns, because humans prefer comfortable similarity to lateral thinking. ;) Maybe one day someone will build a massively parallel neural-net based CPU though, and assembly language will undergo a radical change...... :D
---PS3dev

This topic is closed to new replies.

Advertisement