the power of assembly

[gamenovice]

i heard of assembly before but never really got to know what it is

i am looking it up as of now, but i thought i could some of you guy's input as to why its so great

thank you to those who reply

if anyone flames me for asking a noobish question such as this, i dont blame you

[gamenovice]

ps. i only made this post b/c i have not seen a post truly dedicated to assembly and was curious to what it is

[mv2112]

Assembly is pretty much as close to machine code as your gonna get, this means that assembly is fast, simply because there is no extra "crap" in the code and is directly run by your processor. I believe assembly is assembled directly into machine code, although i may be wrong, either way, its fast. However, its rather cryptic and hard to read. Also, its VERY platform dependant, from Windows to Linux to Mac, and from there, different CPU Architectures. Ultimantly, you should probably stick with C/++ or whatever language you are using simply because assembly is SUPER low-level and requires more thought in planning the program itself. It is also very hard to debug because of its cryptic nature.

Assembly Compared to C/++

Code: Select all

#include <stdio.h>
#include <stdlib.h>
int main(int argc,char*argv[])
{
       printf("Hello World!\n");
}

Code: Select all

section .data
intro: db "Hello World!",0xa
intro_l: equ $-intro
section .text
   mov eax,4               ; system function 4 (sys_write)
	mov ebx,1               ; file-descriptor (cout)
	mov ecx,intro          ; "Hello World!" with a newline (i think)
	mov edx,intro_l       ; length of hello world string
	int 80h                    ; call the kernel, sending it the registers filled above

With assembly, rather than just calling a function with arguments, you are filling registers (basicly variables) with specific data depending on the function. In linux, you call the kernel to call the function with interrupt 0x80.

Assembly is really only good if you're developing boot-loaders, drivers, etc. (low-level stuff) or if you want a super fast program. If your objective is to do either of those, then use assembly, otherwise, use another language like C++.

[MadPumpkin]

Assembly=Masochism
For more information see mv2112's above post :P. I can honestly only think of one game that was written in assembly. I do realize that plenty were made in assembly in the stone era, but I can only THINK of one. Which is Sonic. I thought it was pretty amazing that a game with that much math could run on a Genesis, till I found out it was in assembly :P. But if you want to know more about it read up on it, it's pretty interesting stuff. Trying to make any sort of graphical software with it is what I like to describe as "submitting your brain to torture". People of course will argue, but even they will tell you how much easier it is and a better idea to write with C\++\#, Python or anything else for that matter.

[ismetteren]

Assembly is pretty much as close to machine code as your gonna get, this means that assembly is fast, simply because there is no extra "crap" in the code and is directly run by your processor.

I might be wrong, but i have heard that modern C compilers are better at assembly than the avarage programmer, so the program is probably going to be slower if you write it directly in assembly as opposed to C.

Assembly=Masochism
For more information see mv2112's above post :P. I can honestly only think of one game that was written in assembly. I do realize that plenty were made in assembly in the stone era, but I can only THINK of one. Which is Sonic. I thought it was pretty amazing that a game with that much math could run on a Genesis, till I found out it was in assembly :P. But if you want to know more about it read up on it, it's pretty interesting stuff. Trying to make any sort of graphical software with it is what I like to describe as "submitting your brain to torture". People of course will argue, but even they will tell you how much easier it is and a better idea to write with C\++\#, Python or anything else for that matter.

On platforms like the TI-89 (Graphing calculator) the best games (if not the only games) are in assembly, on the other hand, you can argue that they suck compared to games on other platforms, I do however find bombmaze quite entertaining

But generally, don't use assembly unless you are doing it because you are courious about the lower levels of computers.

[Falco Girgis]

Y'know, there seems to always be a common misconception revolving around "don't use assembly unless you're very very good at optimization."

The C/++ programming language has limitations that often (at an engineering level) MUST be handled in assembly routines. I do realize that this is a very computer-science majory-y oriented board, but lets not forget several things:

1) C provides NO way of accessing hardware registers.

Why does this matter you may ask? 99% of the time it doesn't. But what happens when you are in an embedded environment where peripherals are not memory-mapped (thus cannot be addressed in memory from C/++) and must be directly manipulated via inline assembly?

2) C provides no construct to handle architecture-specific opcodes.

Your operating system uses a fuckton of assembly routines that are being invoked through C for a variety of reasons. Modern architectures provide special-purpose registers, opcodes, and hardware to facilitate many tasks for the operating system. You cannot access a TLB, you cannot do things such as switch the usermode of the processor, you cannot push and pop registers, and perform other low-level tasks in C. Many times, things such as cache misses and page faults raise hardware interrupts that are handled in assembly languages.

While assembly might not have much of a place in the computer science end of the computing spectrum these days, there's an entire engineering arena that demands its use for a software/hardware interface.

[gamenovice]

so when falco was adding psp to the libgyro, was he doing it with assembly to communicate with the processor, or did he simply use psp sdk?

[N64vSNES]

Y'know, there seems to always be a common misconception revolving around "don't use assembly unless you're very very good at optimization."

The C/++ programming language has limitations that often (at an engineering level) MUST be handled in assembly routines. I do realize that this is a very computer-science majory-y oriented board, but lets not forget several things:

1) C provides NO way of accessing hardware registers.

Why does this matter you may ask? 99% of the time it doesn't. But what happens when you are in an embedded environment where peripherals are not memory-mapped (thus cannot be addressed in memory from C/++) and must be directly manipulated via inline assembly?

2) C provides no construct to handle architecture-specific opcodes.

Your operating system uses a fuckton of assembly routines that are being invoked through C for a variety of reasons. Modern architectures provide special-purpose registers, opcodes, and hardware to facilitate many tasks for the operating system. You cannot access a TLB, you cannot do things such as switch the usermode of the processor, you cannot push and pop registers, and perform other low-level tasks in C. Many times, things such as cache misses and page faults raise hardware interrupts that are handled in assembly languages.

While assembly might not have much of a place in the computer science end of the computing spectrum these days, there's an entire engineering arena that demands its use for a software/hardware interface.

I could be wrong but you can use a assembly directly from C/++ code can you not?

for example

Code: Select all

int main ( int argc,char *args[] ) {

	asm("Some assembly shit");

return 0;
}

I guess the is still limits here?

[Trask]

Assembly=Masochism
For more information see mv2112's above post :P. I can honestly only think of one game that was written in assembly. I do realize that plenty were made in assembly in the stone era, but I can only THINK of one. Which is Sonic. I thought it was pretty amazing that a game with that much math could run on a Genesis, till I found out it was in assembly :P. But if you want to know more about it read up on it, it's pretty interesting stuff. Trying to make any sort of graphical software with it is what I like to describe as "submitting your brain to torture". People of course will argue, but even they will tell you how much easier it is and a better idea to write with C\++\#, Python or anything else for that matter.

All the arcade Mortal Kombat games were originally made in Assembly(maybe not MK4, not sure)... when they were later ported to the home consoles, they were then converted to C\++ by a separate company.

I know MK1 used 34010... only because Ed Boon said so on his Twitter account: http://twitter.com/noobde

[Falco Girgis]

I could be wrong but you can use a assembly directly from C/++ code can you not?

for example

Code: Select all

int main ( int argc,char *args[] ) {

	asm("Some assembly shit");

return 0;
}

I guess the is still limits here?

Yes, it's called "inline assembly" when you include assembly code within your C/++ source. You'll have to Google the exact syntax (its compiler dependent).

And hell no, I'm not going "straight assembly" on the PSP. However, on both the Dreamcast and PSP, there are special-purpose registers and opcodes for extremely efficient math, matrix, and vector routines that could substantially improve performance. These are literally inaccessible in C/++.

So yes, if we want libGyro to not suck, we definitely need to use some inline assembly to offload some of the calculations from the CPU and use appropriate hardware acceleration.

[gamenovice]

glad to know

[houston]

Today it's not really a good idea to use assembly for a few reasons, portability for one but there are other reasons.. C/C++ compilers today are very well designed and a lot better then those of say just 10 years ago when using inline asm was still used quite a bit, but today the optimization of the compiler can 99 times out 100 produce better/faster code than you. If you include inline asm take a look at what the compiler does just before using your inline code, it does some very expensive pushing of just about everything registers stack pointers the lot and of-course the pop after your code to restore everything.. Short inline stuff is then the worst of all crimes leading to a lot of unnecessary prologue and epilogue register handling. Just let the compiler do its stuff and don't interrupt its flow, it will do it better thats what the optimization flags are for.

[gamenovice]

so what im getting from here is that assembly by now is mainly good for allowing your engine to access registers of hardware devices. basically in theory if you can do this successsfully, you could completely control your console? please tell me if i am accurate or not, as i am still trying to understand the ins and outs of this language(i know, is should know alot more by now, but im still a noob)

EDIT:
but i can obviously infer that the major uses of it have been replaced by modern compilers, thank god!

[houston]

so what im getting from here is that assembly by now is mainly good for allowing your engine to access registers of hardware devices. basically in theory if you can do this successsfully, you could completely control your console? please tell me if i am accurate or not, as i am still trying to understand the ins and outs of this language(i know, is should know alot more by now, but im still a noob)

EDIT:
but i can obviously infer that the major uses of it have been replaced by modern compilers, thank god!

C was the replacement for assembly, say for example:

C code

Code: Select all

register unsigned int x = 44; 

in assembly could translate to:

Code: Select all

mov bx, 44

C is the lowest "high level" language to the "low level" assembly language!
Assembly is an "almost 1:1" mapping of opcodes to machine language, when you compile a C program your compiler really produces assembly that is then assembled, as shown above

Code: Select all

unsigned int x = 44;

would then become perhaps!

Code: Select all

mov bx, 44

I should point out the the above assembly would then be assembled to something like "0x83 0x2c" in machine code on a x86 instruction set. Note sure about the value for MOV because I don't write in machine code lol, so that is the 1:1 mapping.


houston.

[Falco Girgis]

C was not designed to "replace" assembly, and it could not possibly ever do that. As I said before, there are processor-specific opcodes and registers can provide extremely useful functionality that are literally inaccessible due to the platform-independent nature of higher level languages.

Yes, as far as general software development goes, there is almost no compelling reason to go that low level. But there are still times and places (especially when integrating with hardware or working on embedded platforms) where you literally do not have any choice.