well from what i have learned, i might be wrong, when you assemble the assembly code, you need to link to some system dynamic lib (.dylib for mac, .so linux, .dll windoze) for kernel function calls that you need (like. print to tty, or get file or something like that) When you program is the loaded the loader fixes up those dynamic lib calls in your memory space. (as well as stuff you might not of asked for).

This is the basics. It is really much more complicated in a modern OS like OS X.

like I like to know in the program, the ascii "Hello World!\n", how does the OS know how to print them to the screen?

I want to start from here. thanks

Click to expand...

The section that starts " li r0, 4 ; syscall number (sys_write)" is what you're interested in. You request the services of the operating system via system calls. The quoted line specifies the system call (sys_write) and the next three lines load the arguments to the call (similar to passing arguments to a C function). The "sc" instruction then asks the system to run the specified call.

PPC gurus, please correct any mistakes I've made.. I'm going off of very general knowledge here.

OK, I'm a dumbass... to answer your actual question, the kernel knows to write the output to STDOUT because of two things. The first is the "syscall number" referenced in the comment. The kernel contains a table of system calls, each with a unique identifying number. The assembly language program loads the syscall number for the desired system call (4, for sys_write) into the correct register (r0). Next, the first argument loaded specifies a file descriptor number. The system call will write the requested data to the stream pointed to by the specified file descriptor. In this case, we want the file descriptor for STDOUT, which is 1.

I kinda understand now, but only to that little helloworld, how do i go from here? the url provided is way too complicated for a newbie, for example, how do I take a input and display it on the screen, some User interaction would be nice, right?

thanks

again, apple has too little resources for ppl to learn, maybe it is good, so it doesn't have too much competition, in a way, isn't it?

Stay away from assembler ! unless you have a good reason.
Although the "eieio" instruction sounds cool :^)

The assembler skill is not portable.

I'm an embedded systems programmer. Any project under my control, we stay away from assembler unless absolutely neccessary. The only places I used assembler are: hardware setup code, ie chip selects and setting up the stack for C. and DSP code for filter loops that the C compiler doesn't do a good job on. Either way it's only a page of code.

In my mind :

Code:

main {
printf("Hello World!\n");
}

Is easier and a better use of your time.

Saying "assembler runs faster" doesn't hold if you haven't profiled your code. If speed is of the essence, then algorithm development is more important.

There is absolutely nothing wrong with starting computer programming with assembly.

In Windows' world, there s win32asm, there are thousand of tutorial to show how to program in window's platform with asm.

so please stop flaming 'newbie' and just answer the question if you know the answer.

Not try to be rude, just to be straight up. No time to waste on forum.

Flynnstone,
thanks for your advise, i have my own reason which is simple: get to know the core of what Mac is doing. It is a hobby, maybe never be a expert, just to learn.

Click to expand...

It is not about flaming or lecturing anyone. If you want to program in assembly, then program in assembly. However, it should do you well to understand something very important about assembly language programming on RISC-based systems like the Mac.

It makes sense to program in assembly when performance is paramount. This, however, tends to be true for CISC processors but not RISC. High-level language compilers on CISC tend to generate assembly code that is less-efficient that which can be developed by a competent assembly language programmer. CISC assembly language instructions tend to be flexible enough that complete programs can compete on development time with those written in high-level languages. For CISC, the performance increase payoff and the relative modest cost in development time makes assembly language application development a good choice for many projects.

The whole point of RISC is to include only those instruction in the ISA that are commonly used by compilers. This being the case, high-level language compilers tend to be much more efficient. Only the expert assembly language programmer can be expected to rival the output of a high-level language compiler. On the other side of the coin, assembly language instructions are much simpler. This means that it takes more RISC instructions to accomplish a particular task than are required using CISC instructions. More lines of code means that the cost of development increases even faster. The result is an application that may not match the performance of same application written in a high-level language at a much higher cost.

Bottomline: Assembly language programming on RISC-based systems like the Mac is a waste of time and money except in a few limited situations. However, if you want to do it as a hobby, it is your time and money. If you want to do this on the job, then your boss is wasting his money on your salary.

I'd just like to throw my 2 cents in to the fray. Understanding assembly is a good thing (TM), if not just so you can understand how altivec instructions work and how to get good performance out of them.

I know when doing altivec stuff you have to work on a very low level. Things like loading constants form memory are a big no-no.

Assembly is also good if you every want to get into ,

Low level OS stuff, or embedded systems. Now i would not suggest to be a master at assembly. No two ISA are the same, and there a alot of little differences(like memory addressing modes ) , BUT in my computer design class we learned MIPS assembly to understand how exactly CPUs, and compliers work, and IMHO it is a good thing (TM).

MacRumors attracts a broad audience
of both consumers and professionals interested in
the latest technologies and products. We also boast an active community focused on
purchasing decisions and technical aspects of the iPhone, iPod, iPad, and Mac platforms.