I am trying to learn basic programming with Cheat Engine and games.
So far, I still can't grasp the pointer, particularly how to trace them.
Most of the tutorials on pointers work with 4-bytes long addresses, but what I have is 6-bytes long address. So far I have failed to track down the base address from this 6-bytes long address.
As shown in the screenshot, R9 is the offset and RCX should lead back to the pointer. R9 stays the same while RCX changing each time the game restart. Where should I go from here?
32bit Address space uses 32bit(4 Bytes) for memory addressing, while 64bit Address space uses 64bit(8 Bytes) for memory addressing.
In practice, 64bit is much, much more than required (larger than the estimated storage size of the entire internet) and hence systems have decided to use 48bit(6 Bytes) to address their memory.
Since most programming languages and computers in general only support 32bit and 64bit(do not support 48bit), the 48bit address is stored in a 64bit variable/register, with the higher most significant Bytes being zero (0x0000)
Therefore, in order to scan for the pointer value, you have to scan for an 8Byte value(with hex value being ticked as CE shows address values as hex by default)
Related
In this Diagram found in Wikipedia, both ROM and Program Address Register are connected to a 8-bit bus, but I thought in 8051, Internal Rom uses 16-bit adrress.
So why is the Program Address Register connected to a 8-bit bus?
Since we are not the ones who designed this architecture, we can only guess or think of reasons. If you actually want to know why, you need to find the ones who made the decision.
The 8051 multiplexes the lower address byte and the data on P0, and the upper byte of the address can go through P2. Because both bytes can be transferred at different times, an 8-bit bus suffices.
This design decision could be made to reduce silicon needs, in terms of transistors and wires. Silicon area was expensive that time.
There might be a history in the issue, too. The 8051 series followed the MCS48 (8021, 8022, 8048, etc) that had fewer address bits.
Think about the time this controller was designed, and the target market. External RAM or memory-mapped peripherals might only need 8 bits of address, just because it was enough, or too costly to use more.
Another reason might be over-simplification in the diagrams, that additionally may base one on the other. The program address register might use two 8-bit busses, each connected to one port driver block. And some "wise" guy simply put them together.
The Adress bus is not only connected there, the first 8 bits are common for address and data bus in port 0 of the microcontroller (That's why you see AD0 for the pins in pin diagram for port0, A - Address, D - Data. But in port 2 you find A0, only address), basically, an optimization to reduce the number of hardware connections, the remaining 8 bits i.e most significant bits of the address bus is in port 2 of the microcontroller so totally 8 + 8 = 16 bits.
I am getting a little bit deeper in exploring the STM32's MCU and I went bare metal. I am using an STM32F103C8T6 BluePill.
Just to make sure I'm fully understanding what is going on, what is the nature of the addresses of the MCU? I mean, for my board, the RCC boundary address is 0x4002 1000 - 0x4002 13FF and by creating a custom named pointer to this address and type casing this "0x40021000" to be treated as an actual address by the compiler, is this an address of an actual register?
I mean what I understood is that the MCU has 32bit registers, those registers have addresses, those addresses are the addresses of the registers and each 32bit register in the MCU has a unique address, a physical one! And therefore to manipulate a specific register we create a pointer to the address of that register and then dereferencing the pointer and change the register it is pointing to.
For example, the RCC address starts at "0x40021000" and this address is of the register 0x0000XX83 (where X is undefined as per the reference manual), Am I right? Do those registers actually have addresses in the MCU so they can be accessed and manipulated? If so, are those registers bits are just transistors where when setting a bit in that register to 1 the transistor turns on?
Also if what I understood was correct, does that mean that the Reset Values are the actual register values which have addresses (as in registers are analogous to variables e.g x,y, etc.. and there addresses are those in the reference manual as in RCC address = 0x40021000 and dereferencing this address gives us 0x0000XX83 ??
I know I might have confused you but this is the best I can explain!
Thank you in advance.
Addresses are addresses on the bus*. When the compiler generates an instruction for the processor to read an address (LDR) it asks the bus to fetch what is at that address. Similarly a write instruction (STR) tells the bus what the address is and what data it wants to put there.
At the other end of the bus could be anything, but in most cases it will be either memory or a memory-mapped peripheral register. This could have any number of bits, but the most you can access in one go is 32. This is because the width of the bus is 32-bits. The datasheet lists the address ranges used by each peripheral, and the reference manual says what purpose of each peripheral register is.
In your example the RCC is a peripheral, its address range is 0x40021000-0x400213FF. The first register in the RCC is RCC_CR, which has address offset 0x00, making its address equal to 0x40021000. 0x0000XX83 is the value of the RCC_CR register at boot.
There are another set of registers which instructions can access directly. These are the processor core registers. Because they are not accessed through the bus they do not have an address. Most of the processor core registers have 32-bits and that is why the STM32 is called a 32-bit microcontroller.
(*in a Harvard architecture part like the Cortex-M3 used in STM32F1 there are actually several buses sharing an address space but as a beginner I would suggest you can overlook that.)
In terms of transistors, each bit in a register is usually made of more than 1 transistor. Often 6 transistors are wired together to make a flip-flop which represents a single bit.
I try to monitor some Cisco 2960x Switch devices and I know there are the SNMP OID's ifInOctets (32-bit Counter) and ifHCinOctets (64-bit Counter). Can someone explain me whats the difference between those Counters and which one I should use for a GigabitEthernet Interface?
Thanks
64-bit counters are used for high capacity interfaces where 32-bit counters do not provide enough capacity and wrap too fast.
As the speed of network media increases, the minimum time in which a 32-bit counter wraps decreases.
For example, a 10 Mbps stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes. At 100 Mbps, the minimum wrap time is 5.7 minutes, and at 1 Gbps, the minimum is 34 seconds.
For interfaces that operate at 20,000,000 (20 million) bits per second or less, you must use 32-bit byte and packet counters. For interfaces that operate faster than 20 million bits per second, and slower than 650,000,000 bits per second, you must use 32-bit packet counters and 64-bit octet counters. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet and octet counters must be used.
You can check the following link for detailed explanation on SNMP counters.
I'm using intel integrated gpu for my opencl implementation. I am implementing a program with zero copy where I'm not copying the data to the gpu instead it shares the common memory(RAM).
I have a 64bit cpu, but in gpu specs it shows it has only 32 bit addressing mode.
I'm sharing a malloc heap space between the gpu and cpu and when I print the address I see the following.
In GPU:
if(id==0){
printf("Mem address: %p\n",A);
//Outputs Mem address: 0x1010000
In CPU: it prints
printf("Outside Mem address: %p\n",cpuA);
Device: Intel(R) HD Graphics IvyBridge M GT2
Outside Mem address: 0x7fcd529d9000
I am not getting how is it mapped in gpu. And I wonder if 2^28/2^32 is the maximum address gpu could access?.
The memory address you are printing on the host is a virtual address that only makes sense in the context of your program's process. In the CPU, this is transparently translated to a physical RAM page, the address of which is unrelated to the virtual address but stored in a lookup table (page table) maintained by the operating system. Note that "64-bit CPU" typically refers to the number of bits in a virtual address. (Although many 64-bit CPUs actually ignore 8-16 bits.) The number of bits for physical addresses (for addressing physical RAM cells and mapped device memory) is often a lot less, as little as 40 bits.
Devices attached to the system and able to perform direct memory accesses (DMA) most commonly deal with physical memory addresses. If your Intel GPU does not have an internal memory mapping scheme (and there is no IOMMU active, see below) then the address you are seeing in your OpenCL kernel code is probably a physical memory address. If the device can only address 32 bits, this means it can only access the first 4GiB of physical memory in your system. By assigning memory above 4GiB to devices and user space processes that aren't affected by a 32-bit restriction, or by using "bounce buffers", the operating system can arrange for any buffers used by the restricted device to be located in that memory area, regardless of virtual address.
Recently, IOMMUs have become common. These introduce a virtual memory like mapping system for devices as well - so the memory addresses a device sees are again unrelated to the physical addresses of system memory they correspond to. This is primarily a security feature - ideally, each device gets its own address space, so devices can't accidentally or deliberately access system memory they should not be accessing. It also means that the 32-bit limitation becomes completely irrelevant, as each device gets its own 32-bit address space which can be mapped to physical memory beyond the 4GiB boundary.
if machine A and machine B are communicating with each other, but they are with different host byte order
then in network-programming,on the sending side, should tcp/udp data field be converted to network byte order
why?
thanks!
Unless you're following a pre-existing specification, it will be safest to always use network byte order (aka "big-endian"):
You need to specify some byte order; you can't just send binary data and hope that the receiver can figure it out.
Because big-endian data is a standard of the Internet, there are lots of tools to convert to/from host byte order. You'd have to write your own tools to convert between host and little-endian.
The traditional argument against is "all the world's a VAX" (or today, x86), which is little-endian, and so network byte order imposes a performance tax on data. Perhaps that was a valid argument 20 or 30 years ago, but it certainly isn't today. The amount of time that your processor takes to convert data is an infinitesimal fraction of the time it takes to move that data across the network.
It is certainly recommended in many cases. To explain the reason why, let's look at an example:
You have a program that takes a 32-bit unsigned int, places it in a packet and sends to another host
The other host pulls the data out of the packet and stores it as a 32-bit unsigned int.
Sending host is big endian, receiving host is little endian.
If the sending host in the above example sends the number 1024, that number is stored on the sending host's machine as 0x00000400. If the receiving host doesn't change the byte order when receiving those bytes and stores 0x00000400 in memory, this will be interpreted as a totally different number than 1024. The little-endian representation of the decimal number 1024 would be 0x00040000. On a little-endian machine, 0x00000400 is the decimal number 262,144.
Converting to network-byte order allows the programs to rely on a standard encoding of the data to avoid confusion like we see in the above example. Functions on the receiver side to convert from network-byte order to whatever byte-order it uses are easily available and simple to use.
TCP has built-in mechanisms for re-ordering received packets. UDP hasn't. I'm not sure what do you mean by "different host byte order", but it the packets are received with byte-level errors then that's the layer 2 role to retransmit such a packets.