x86 assembly- registers. What about RAM?

[kowboy_koder]

Hi all.

This is my first question on the forum (there will probably be many more to come as I further my knowledge of assembly lol). I'm just walking through the tutorials at http://www.skynet.ie/~darkstar/assembler/ and there is one question that immediately popped into my mind.

I've only just stepped into the world of assembly programming (for the past 5-6 years I've been developing with higher level technologies though), and it seems to me so far that registers are the primary form of data storage for apps written in assembly, as opposed to RAM, which is used by other technologies. Is this true, that assembly programs only use registers within the actual CPU itself to store data and not RAM?

Naturally this would be much more efficient just thinking of the fetch-execute cycle, but what about when a user runs more than one assembly program at a time, or if an assembly program needs to store quite a lot of data simultaneously? The registers wouldn't be able to store so much information. What then?

I'm just coming to this conclusion because when you look at the 'MOV' instruction, common paramaters passed to the command are register addresses (AX, AH, DX, etc).

Any clarification is much appreciated =]

[hutch--]

Assembler in 32 bit uses memory (RAM) registers and immediate values (numbers).

Code Select Expand


mov eax, 1    ; copy an immediate number into EAX register
mov eax, ecx  ; copy ECX into EAX
mov eax, mem  ; copy memory operand into EAX


Optus net huh ? Sydney local myself.

[Ficko]

Hi ..koder!

Registers primarily intended to be temporary storages, relay points between memories since the most CPUs have no instructions available to move data directly memory to memory.
Whoever for fast execution on low complexity algo it is possible to minimize memory access using regs exclusively but you usually will run out very fast on registers.
Some high level compilers are able to use mmx regs as temporary storage as well and on 64 bit system you have a much wider range of GPRs at hand.

[Slugsnack]

your question of simultaneous execution of multiple processes is known more commonly as 'concurrency'. there are many algorithms the cpu can use to ensure good distribution of cpu time to each process, time slicing, round robin, priority based, etc. etc. because of how quickly the processes are switched it gives the impression to the user that they are running concurrently. the way that registers are not trashed as soon as we 'switch process' is something known as a 'context switch'. the 'context' of a given process is saved before switching to the next process. this context includes registers, flags, current program counter, etc.

btw memory is used in assembly programming too. in fact there are many cases when memory is NEEDED. if you bear in mind that stack is also essentially memory, you can see that memory is still a vital resource. however you are correct in the aspect that assembly programmers will do their best to maximise register use. compilers for high level languages will often attempt to do the same thing

[WryBugz]

Hi Kowboy - welcome to the forum and assembly.

A fun way to get started may be to disassemble one of your high level language programs into assembly. You will then see that the high level language does everything the guys are talking about. The appeal and fun of assembly is that you get to program more or less directly to the machine. It takes a long time before you will ever write anything better than your compiler, but they say, learning just a little assembler will amke you a better programmer in your high level language.

And besides, it is fun. And the old grumpy men in the forum will grow on you.

[PBrennick]

high level compilers are able to use mmx regs

This is an interesting statement that will cause people to come to the wrong conclusion. mmx registers are used in assembly all the time and are NOT exclusive to high level compilers. Have you looked at Ray's stuff in the masm32 or GeneSys packages?

Paul

[Ficko]

This is an interesting statement ...

You right it could be formulated better. :bg

I just assumed it is obvious that in assembler you can do everything possible and moving up the line to high level languages
you usually run into restrictions and barriers not to be overcome otherwise than inserting inline assembler codes. :wink