1. If I initialize a variable 'a' (in the SRAM), can it happen that its location/position in memory changes each time I simulate or add other variables to the program? Or will it always remain in that location? (if I don't change it manually of course)
2. I would like to find out whether it's possible to save within a variable 'a' the memory address in which another variable 'b' is stored. Which function can I use?
Thanks!
(I am working on STM32CubeIDE)
Related
I am trying to write a basic cmake to check whether certain types exist or not.
I am having issues with calling check_type_size multiple times. If I used the same variable (the one that holds the size) multiple times, only the first time I call check_type_size it gets populated.
cmake_minimum_required(VERSION 3.8)
project(TEST LANGUAGES C;CXX)
INCLUDE (CheckTypeSize)
check_type_size("int" VAR_SIZE1)
message(${VAR_SIZE1})
check_type_size("void *" VAR_SIZE1)
message(${VAR_SIZE1})
message("VAR_SIZE1 was not updated after the second call.\n")
check_type_size("int" VAR_SIZE2)
message(${VAR_SIZE2})
check_type_size("void *" VAR_SIZE3)
message(${VAR_SIZE3})
message("We get the correct size if use different variable every time.")
add_executable(TEST "${TEST_SOURCE_DIR}/main.cpp")
This is what I get:
Check size of int
Check size of int - done
4
4
VAR_SIZE1 was not updated after the second call.
Check size of int
Check size of int - done
4
Check size of void *
Check size of void * - done
8
We get the correct size if use different variable every time.
Does any body know what is going on?
Variable created with check_type_size() call is actually a CACHE variable (this is described in the documentation for the macro. Once variable is set, its is not updated. [This is used for omit successful checks next time you run cmake.]
Different checks should use different variables.
Suppose that we have variable (x) allocated in the memory and assigned a constant value (v). Are there cases where the operation of reading the content of the variable changes its value?
Thanks.
This is going to be a pretty loaded question but ever since I started learning about pointers I've been very curious about what happens behind the scenes when a program is run.
As far as I know, computer memory is commonly thought of as a long strip of memory divided evenly into individual bytes. Certainly pictures such as the following evoke such a metaphor:
One thing I've been wondering, what do the memory addresses themselves represent? I'm sure it's no coincidence that memory addresses appear as 8 digit hexadecimal values (eg/ 00EB5748). Why is this?
Furthermore, when I declare a variable x, what is happening at the memory level? Is the compiler simply reserving a random address (+however many consecutive addresses it needs for the variable type) for data storage?
Now suppose x is an unsigned int that occupies 2 bytes of memory (ie values ranging from 0 to 65536). When I declare x = 12, what is happening? What is it that I'm making equal to 12? When I draw conceptual diagrams, I usually have a box for an address (say &x) pointing to a variable (x) that occupies seemingly nothing, and I'm sure that can't be a fully accurate picture of what's going on.
And what's happening at the binary level? Is the address 00EB5748 treated as 111010110101011101001000 and storing a value of 12 somewhere, or 1100?
Mostly my confusion & curiosity stems from the relationship between memory addresses and actual values being declared (eg/ 12, 'a', -355.2). As another example, suppose our address 00EB5748 is pointing to a char 's' whose value is 115 according to ASCII charts. Is the address describing a position that stores the value 115 in 1 byte, by flipping the appropriate 1s and 0s at that position in memory?
Just open any book. You will see pages. Every page has a number. Consecutive pages are numbered by consecutive numbers. Do you have any confusion with numbered pages? I think no. Then you should not have confusion with computer memory.
Books were main memory storage devices before computer era. Computer memory derived basic concept from books: book has pages -> computer memory has memory cells, book has page numbers -> computer memory has memory addresses.
One thing I've been wondering, what do the memory addresses themselves represent?
Numbers. Every memory cell has number, like every page in book.
Furthermore, when I declare a variable x, what is happening at the memory level? Is the compiler simply reserving a random address (+however many consecutive addresses it needs for the variable type) for data storage?
Memory manager marks some memory cells occupied and tells the address of first reserved cell to compiler. Compiler associates name and type of variable with this address. (This picture is from my head, it can be inaccurate).
When I declare x = 12, what is happening?
When you declared variable x, memory cells were reserved for this variable. Now you write 12 into these memory cells. Note that 12 is binary coded in some way, depending on type of variable x. If x is unsigned int which occupies 2 memory cells, then one cell will contain 0, other will contain 12. Because binary integer representation of 12 is
0000 0000 0000 1100
|_______| |_______|
cell cell
If 12 is floating-point number it will be coded in other way.
A memory address is simply the position of a given byte in memory. The zeroth byte is at 0x00000000. The tenth at 0x0000000A. The 65535th at 0x0000FFFF. And so on.
Local variables live on the stack*. When compiling a block of code, the compiler counts how many bytes are needed to hold all the local variables, and then increments the stack pointer so that all the variables can fit below it (along with some other stuff like frame pointers and return addresses and whatnot). Then it just remembers that, for example, local variable x is at an offset -2 from the stack pointer, foo is at an offset -4 and so on, and uses those addresses whenever those variables are referenced in the following code.
Since the compiler knows that x is at address (stack pointer - 2), that's the location that is set to the value 12 when you do x = 12.
Not entirely sure if I understand this question, but say you want to read the memory at address 0x00EB5748. The control unit in the CPU reads the instruction, sees that it is a load instruction, and passes the address (in binary of course) to the load/store unit, along with some other junk like how many bytes to read. Then the LSU sends that address to some memory (probably L1 cache), and after a certain time gets the value 12 back. Then this data is available to, say, put in a register, or send to the ALU to do arithmetic, or whatever.
That seems to be accurate, yes. Going back to the first question, an address simply means "byte number 0xWHATEVER in memory".
Hope this clarified things a bit at least.
*I should probably explain the stack as well. A stack is a portion of memory reserved for local variables (and some other stuff). It starts at a fixed location in memory, and stops at the memory address contained in a special register called the stack pointer. To begin with, the stack is empty, so the stack pointer just contains the start of the stack. As you put more data on the stack, the SP is incremented. This means that you can always put more data on it simply by putting it at the address in the SP, and then incrementing the SP so that once again anything past that address is free memory.
On the website I am writing, there is an object called person which holds a variable called balance. At one point I call the set method and change balance's value to 100 from 0.
I noticed there was a problem when the at the end running my program the value of balance was back to 0. Placing a break point where it changes balance with the code
User.person.balance = Date.Parse(txtBal_Updated.Text)
it goes through the setter and changes the value from 0 to 100. I stop the program right after this change and use the tracer to look at the value of balance and it say 100. But if I look at person and through person to balance it shows that it is 0. Then when I look back at balance it has suddenly changed back to 0 without me stepping through the program at all. I am very confused how an objects value can change without the program running.
What is the thing that you call “your program” ? Is it some JavaScript in a Web page ? How do you run it ?
What is “the tracer” ? With what tool(s) you inspect the variables ?
Your problem makes me think strongly of variable scope. You may experience some garbage-collecting too.
You focus on the variables themselves. In your situation, I suspect first the instrumentation.
I have an array and a variable declared like this
NextPacketRegister : array (1 .. Natural (Size)) of Unsigned_32;
PacketBufferPointer : Unsigned_32;
for PacketBufferPointer'Address use To_Address (SPW_PORT_0_OUT_REG_ADDR);
for NextPacketRegister'Address use To_Address (16#A000_0000# + Integer_Address (PacketBufferPointer));
PacketBufferPointer points to an HW registers that you access thru the PCI of our board.
NextPacketRegister uses this register's value + 16#A000_0000#
The thing is everytime I access NextPacketRegister, behind the scene I perform a PCI access, these access are very slow and we are trying to remove this limitation.
But I can't seem to find a way to modify NextPacketRegister'Address during runtime (I'd like to read ONCE the PacketBufferPointer register and then add this value + 16#A000_0000# only once so I don't have to perform PCI access everytime.
I looked around but I have no clue how I could achieve this.
That is correct; if you use for ...'address use to overlay an object at a specific address, you cannot change it later.
Generally I try to avoid overlays. What you show is one drawback to them. Another is that if the object has any parts that require initialization, they will be reinitialized every time the object is elaborated.
One thing I do have to ask up front though: This looks like a device driver. If you don't like the hit from going to the PCI bus then, fine. The obvious way around your problem of course is to just read the object into a temporary variable and use that when you don't want to hit the PCI bus. But obviously when you do that you are no longer reading directly from the device, and thus won't see changes it made to its memory-mapped registers (and your changes won't go straight to those memory-mapped registers). That's what you want, right? Ada contains no magic to allow you to get data on and off the PCI bus without hitting the PCI bus.
It almost looks like you are thinking that this line:
for NextPacketRegister'Address use To_Address (16#A000_0000# + Integer_Address (PacketBufferPointer));
Means: "Every time I access NextPacketRegister, go find the value of PacketBufferPointer and overlay it where it happens to be right now". That is not the case. This will only happen once when your declaration is processed. Thereafter, every access to something like NextPacketRegister[12] will go to the same place, without any access to PacketBufferPointer.
Another way would be to use pointers and Unchecked_Conversion. That's generally my preferred solution for overlays. It looks hairer, but what you are doing is hairy, so it should look that way. Also, it doesn't perform initializations on the overlaid memory area. I suppose that could be a bad thing though, if you count on those. Of course overlaying this way could cause an access to PacketBufferPointer, if you want. You'd have control over it depending on how you code it.
Since you asked about pointers, in this case I think you have a very valid case for using the package System.Address_to_Access_Conversions. I don't have the compiler handy, but I think it would go something like this:
type Next_Packet_Array is array (1 .. Natural (Size)) of Unsigned_32;
package Next_Packet_Array_Convert is new System.Address_To_Access_Conversions
(Next_Packet_Array);
Synced_Next_Packet_Address : System.Address;
Now when you "sync", I guess you'd want to hit that PacketBufferPointer to get the register value (as a SYSTEM.ADDRESS), and save it into a variable for later use:
Synced_Next_Packet_Address = 16#A000_0000# + Integer_Address (PacketBufferPointer);
And when you want to access the Next_Packet_Array, it would be something like this: Next_Packet_Array_Convert.To_Pointer (Synced_Next_Packet_Address).all
Make a structure (array of buffers ? ) that is what your set of packet buffers looks like and sit that at the address of the start of the array.
read the array index from the register.
you can write C in any language, even Ada.
At least it works and you get some sensible bounds checks.