I am fairly new to programming and am starting to learn the ins and outs of memory allocation. One question that recently occurred to me that I haven't yet been able to find a clear answer to is do memory addresses themselves take up memory. For example, in a 32-bit system, the way I understand it is that each address in 4 bytes and they will typically refer to an empty 'bucket' in memory that is capable of storing 1 byte of data. Does this mean that for each memory location in a 32-bit system, we are actually using 5 bytes of memory(meaning 4 for the address and 1 for the empty bucket)? I'm sure I am missing something here but any clarification would be much appreciated. Thanks!
To reference a memory address you need to express that memory address somehow, and on 32 bit system a memory reference takes 4 bytes indeed. So for any addressable memory address, somewhere else in memory there are 4 bytes that have that address.
But this does not cascade to an x5 multiplication, because a program does not need to reference every byte of memory. It only needs the address where something in memory starts, and then it can work its way to every byte of that 'something' using arithmetic.
To give an example: you have a string in memory Justin Foss. Is it at address 0x10000000, and this address is stored in a variable. So the actual variable value is 0x10000000, pointing to the string Justin Foss. But at 0x10000000 you only have one byte, the J. At 0x10000001 there is the u, at 0x10000002 is the s and so on. Your application does not need a variable for each character, it only needs one variable (4 bytes) to the beginning of the string. Same for object (fields): you only store the address where the objects starts, and the compiler know how to do the arithmetic to find the field it needs, by adding the necessary offset. In general memory objects are quite large, and a few 4 byte variables in the program reference quite a bit of memory.
(at the risk of oversimplification) Memory is sequential. Address 123 is the one-hundred and twenty third byte from the first (zeroth) by in the system. There is no memory devoted to indicating byte 123 is 123. The byte that comes after that is 124.
Related
I worked with megafunctions to generate 32bit data memory in the fpga.but the output was addressed 32bit (4 bytes) at time , how to do 1 byte addressing ?
i have Altera Cyclone IV ep4ce6e22c8.
I'm designing a 32bit CPU in fpga ,
Nowadays every CPU address bus works in bytes. Thus to access your 32-bit wide memory you should NOT connect the LS 2 address bits. You can use the A[1:0] address bits to select a byte (or half word using A[1] only) from the memory when your read.
You still will need four byte write enable signals. This allows you to write word, half-words or bytes.
Have a look at existing CPU buses or existing connection standards like AHB or AXI.
Post edit:
but reading address 0001 , i get 0x05060708 but the desired value is 0x02030405.
What you are trying to do is read a word from a non-aligned address. There is no existing 32-bit wide memory that supports that. I suggest you have a look at how a 32-bit wide memory works.
The old Motorola 68020 architecture supported that. It requires a special memory controller which first reads the data from address 0 and then from address 4 and re-combines the data into a new 32-bit word.
With the cost of memory dropping and reducing CPU cycles becoming more important, no modern CPU supports that. They throw an exception: non-aligned memory access.
You have several choices:
Build a special memory controller which supports unaligned accesses.
Adjust your expectations.
I would go for the latter. In general it is based on the wrong idea how a memory works. As consolidation: You are not the first person on this website who thinks that is how you read words from memory.
I work on a simple AVR programmer for my university project, and I am stuck with understanding how I can map memory from hex file to actual flash memory.
For instance, intel hex provides us the information about start address of data block, number of bytes in it and data itself. The trouble comes from that AVR MCUs, in particular ATmega16, often have one address for two bytes: high and low.
At first, I wrote a straightforward function, that just reads all the data from hex file and write it sequentially, increasing address by one each two bytes passed. To my surprise it works on simple blinky code. However, I am not sure, if this approach would work, if someone needs complex memory structure.
So the questions are:
Will this solution work on complex memory structures?
If not, how can I map intel hex address into actual flash address? The problem is there is no high and low bytes in intel hex format, only address = byte.
Intel hex uses byte addresses. The PC program counter refers to 16-bit word addresses. If you mean the word address to be the "actual address", then just double the number that represents the start address of the line in the hex file.
What do you mean by "complex memory structures"? Memory locations need unique addresses, no matter how that address space is broken up. I am not familiar with program memory spaces that don't start with 0 and continue linearly, but if there were such a scheme, a line in an intel hex file can specify the contents of any contiguous memory section starting at any address.
Edit:
Each line of an intel hex file can only contain up to 255 bytes. Typically, the data is split into 16 or 32 bytes chunks. Each line contains the start address of the chunk (which is added to the base address if used). A chunk doesn't have to start at the end of a previous chunk, and they can be out of order, too.
As for the complex memory structures you describe, most programs have them already. There is usually a vector table at the start, followed by a gap, followed by the crt and main program. Data to initialize global variables follows that. If there is a bootloader, it is placed in a special section at the end of memory.
Quick question on memory locations in IA-32 assembly language that i cannot seem to find the answer for anywhere else.
On IA-32 each memory address is 4 bytes long (e.g. 0x0040120e). Each of these addresses points to a 1 byte value (or in the case of a larger value, the first byte of it). Now look at these two simple IA-32 assembly language statements:
var1 db 2
var2 db 3
This will place var1 and var2 in adjacent memory cells (let's say 0x0040120e and 0f). Now I realize that the define directive db allocates 1 byte to the value. But, in the case above I have two values (2 and 3) that in fact only requires two bits each, to be stored.
Questions:
When using the db directive, do these two values still consume a full byte, even though they are smaller than 1 byte?
Is using a full byte for values that could get away with less, still the common way to go (as we have so much memory that we don't care)?
Does integers 0 to 255 then generally take up 1 byte and integers 256 to (2^16 - 1) take up 2 bytes (a word), etc.?
Thank you,
Magnus
EDIT 1: Made questions more clear (apologies for the back and forth)
EDIT 2: Added a structured reply below, based on other posters' input
yes. the B in DB is for Byte.
You could use a nibble for each, like so:
combined db 0x23
but you'd have to
a) shift the result for 4 bits right if you need the "2".
b) mask the leftmost 4 bits if you need the "3".
Hardly worth the effort these days ;-)
Yes, since the architecture is byte-addressable and cannot address anything smaller than a byte.
This means that data requiring less than one byte will need to share its address with other data.
In practice this means that you're going to have to know which bits in the pointed-out byte are used for this particular value.
For hardware registers this sort of mapping is very common.
EDIT: Ah, you seem to mean "values of the same variable" when you said "2 and 3". I thought you meant 2-bit and 3-bit values. You need to decide how many bits are needed at most for a particular variable, for all the values you need that variable to be able to store. There are variable-length encodings for integers of course, but that's generally rarely used in assembly and not what you'd typically use for some general-purpose variable.
You generally should expect to reserve all bits required for all values that a variable need to hold, up front. Otherwise, if you're worried about "wasting memory", you would need to move all other variables as soon as you get some "vacant bits" somewhere. That would end up costing fantastically much. Also, knowing the size of a variable is constant makes it possible to generate (or write) the proper code to handle it, otherwise you would of course also need to explicitly store somewhere "the size of the value held in variable x is now y bits". That becomes extremely painful very very quickly.
My initial question was a bit unstructured, so for the benefit of other searchers stopping by here I will use the answers received from #unwind and #geert3 to create a structured response. Again, this was my fault due to the initial poor structuring and creds for the answers goes to #unwind and #geert3.
When using the db directive you allocate 1 byte to the variable, and even if the variable takes up less space than 1 byte, it will still consume that full 1-byte address spot. As one might guess, that wastes a few bits of memory, but that is okay as you have enough memory and not too bothered about wasting a couple of bits. The reason you want to use the full 1-byte memory location is that it is easier to reference the variable when it is alone in the address slot (see #geert3's note on how to access it if you use less than a byte), and additionally, in case you want to reuse the variable later, it is great to know you have space for any number up to 255.
Yes, see answer to 1
Yes, you would normally allocate multiples of a byte to a variable, in a byte-addressable system
Endianess determines the ordering of bytes in a word. Let us consider the following
memory system :
so this is a byte addressable 32 bit memory.
If I move a hex value 'val = 0x56789A' into the memory location with word address 0, it will look like this for big endian:
And like this for little endian:
but we know that in the register the values are stored as '56789A' itslef, so that is no problem if we have a big endian type byte ordering, as the value can be loaded in the correct order.
but what about in the case of little endian where the order has to be reversed? In little endian it will be loaded as '9A7856', which is wrong. Then do we store it like this in the memory, (i.e.) have a different organization for little endian type ordering? such as :
Now we can load the value at word address location '0' into a register for any further operation.
this was a possible solution.
but now it would mean that the endianess will dependend on the memory cell arrangement and not exactly the processor...... How exactly does this work?
Or is it the case that endianess is not at all affected by the memory architecture but rather ONLY the processor? So finally Does endianess depend on processor or memory?
Endianness is really a question of interfaces. For a 32 bit register load one interface is asking for a 32 bit value, and the memory interface provides an array of bytes. Something has to resolve that interface. If it resolves the byte array as the low order bytes going into the most significant bits of the returned value, then it is big endian. If it resolves it with the low order bytes going into the least significant bits of the returned value it is little endian.
So, really your question is who resolves those interfaces. Technically, it matters how the processor requests data from the from the memory. If it requests it by saying "I want a 32 bit value" then the memory, which has an array of bytes, must resolve it. If it requests it by saying "I want 4 bytes", then the processor has to resolve it before storing it into the registers.
By convention, the processor resolves this interface. This allows the memory to work with both big and little endian processors because it can present the same interface (a byte array) to both types of processors and just let the processor resolve it anyway it wants it. At the risk of being to simplistic: the processor resolves it in the load/store unit and memory interface unit. The registers never have to think about it because by the time it reaches them, it is an 32 bit value, having already been resolved by the memory interface unit from the byte array it requested from memory.
Assume 32 Bit OS.
One memory location in a computer stores how much data?
Whats the basic unit of memory storage in a computer?
For Example to a store a integer what will be the memory addresses required?
If basic unit is BYTE the integer requires 4 bytes.
So if I need to store a byte then if start putting in the 1st byte in memory location
0001 then will my integer end at 0003 memory location?
Please correct me if am wrong?
Most commonly, modern systems are what you call "byte-accessible".
This means:
One memory location stores 1 byte (8 bits).
The basic storage unit for memory is 1 byte.
If you need to store 4 bytes, and place the first byte at 0001, the last byte will be at 0004. That's one byte at each of 0001, 0002, 0003, and 0004.
Keep in mind while systems have different CPU word sizes (a 32-bit system has a 32-bit or 4-byte word), memory is usually addressed by byte. The CPU's registers used in arithmetic are 4 bytes, but the "memory" programmers use for data storage is addressed in bytes.
On x86 systems, many memory-accessing instructions require values in memory to be "aligned" to addresses evenly divisible by the word size. e.g. 0x???0, 0x???4, 0x???8, 0x???C. So, storing an int at 0001 won't happen on most systems. Non-numeric data types can usually be found at any address.
See Wikipedia: Alignment Word (Computing) Memory Address
One memory location in a computer stores how much data?
It depends on the computer. A memory location means a part of memory that the CPU can address directly.
Whats the basic unit of memory storage in a computer?
It is the Bit, and then the Byte, but different CPUs are more comfortable addressing memory in words of particular sizes.
For Example to a store a integer what will be the memory addresses required? If basic unit is BYTE the integer requires 4 bytes.
In mathematics, the integer numbers are infinite, so infinite memory should be required to represent all/any of them. The choice made by a computer architecture about how much memory should be used to represent an integer is arbitrary. In the end, the logic about how integers are represented and manipulated is in software, even if it is embedded in the firmware. The programming language Python has an unbounded representation for integers (but please don't try a googol on it).
In the end, all computer architectures somehow allow addressing down to the Byte or Bit level, but they work best with addresses at their word size, which generally matches the bit-size of the CPU registers.
It is not about the amount of data, or the size of integers, but about the number of memory addresses the computer can use.
There are 4GiB addresses (for bytes) in 32 bits. To manage a cluster of machines with more than 4GiB of RAM, each system must manage larger addresses.
Again, it is all about the addressable memory space, and not about the size of integers. There were 64 bit integers even when CPUs preferred 8bit word addressing.
Depends on the architecture. 32-bits for 32-bits. 64-bits for 64-bits.
Usually it's called a "word"
Most values need to be aligned, so the addresses end with 0 4 8 or C