views:

52

answers:

3

I am trying to learn assembly language and I need clarification on something. Please correct me if I am wrong on any of this since I don't know much about assembly.

All the tutorials I watch have the variables of assembly programs assigned to a memory address like 0x0000, and I can understand that you must manually assign memory addresses in assembly, but how do you know what address to use?

Obviously it makes sense to start at the lowest memory address possible, but what if the variable you are assigning is larger than the memory available at 0x0000? Would the variable in question run over to 0x0001 or 0x0002? If it did wouldn't that mess up other variables assigned spaces with similar numbering (or are you not supposed to assign them that close)?

If I have two programs written in assembly running at the same time (in a modern OS) and I have used the same memory addresses in both programs, will one program conflict with the other, or does the OS just assign an available memory address regardless of what was actually written in the program?

Any information on the subject is appreciated.

A: 

Depends on the target and the type of memory (RAM, ROM, etc) you are talking about. If you are talking about RAM a small embedded project you may just have a few files to keep track of, and the data sheets for the micro will tell you the various memory region addressing. In the case where there are several 'modules,' you would use a linker to link the object files into an executable. The linker can re-assign memory address so they don't overlap, or you can have a central file where all the memory locations are defined, and the other modules use this as a resource. Sorry. Its a big question with a lot of answers.

JackN
+3  A: 

The answer to the second part of you question (on most modern OSs) is virtual memory.

You start at the hardware layer with physical memory. That's the stuff you can actually poke with your finger. This is what the operating system sees. The operating system lets you run processes on an abstraction called virtual memory.

Each process gets its own virtual memory space. So it can pretend that it's the only process running, and it has tons of memory. Then each time you access memory, you supply a virtual address, which gets mapped to a physical address. The operating system keeps a table of which virtual address gets mapped to which actual physical addresses in RAM. Typically this is done with some special hardware as well (an MMU, memory management unit) for performance reasons, but you could do it 100% in software too.

So when you say 0x000 in your program, that's a virtual address. It gets translated into a physical address by the computer when you read or write. So in another process, the same virtual address 0x000 maps to a different physical address. This system lets you write your program without knowing exactly how much RAM is available, or what address your program will be loaded into. It also prevents your program from trashing memory that belongs to another program.

As for the first part, absolutely. Different types of data take different amounts of memory. You have to know how much space you need when you lay out your data structures. There are also byte-alignment issues to keep in mind. Multi-byte data types (eg floating point numbers) often have to start at an address that is divisible by 2 or 4 or the number of bytes it takes to store a float -- it's a requirement of the processor or the RAM. So you can't just crunch all your data together, one byte after the next, you have to lay it out in a specific order like fitting together the pieces of a puzzle if you want to minimize unused memory.

Alex Martini
Thanks for the detailed answer! In the last part of your answer, how does one accurately calculate how much space is needed for each bit of data? manually calculating hundreds of variables for a program does not seem feasible. Using your words, how do you `lay it out`?
typoknig
I've never worked with assembly in any large projects, but the heuristic that was recommended in my OS class was to sort your variables by size, and then put the smallest ones at the lowest memory addresses. This isn't always the best layout -- you might be able to fit small data types in between big ones.You should be able to tell from the variable's type how much memory it needs -- consult the documentation for your assembly language. Remember, a variable takes up the same amount of memory through the entire run of your program. It can't "grow". That's why overflows happen.
Alex Martini
A: 

This is not exactly an answer but in this book there is the answer. I can only recommend it. It will teach you the basics, like the name says it's Programming from ground up.

ProgrammingGroundUp

Octavian Damiean