0

I'm trying to understand addressing and memory. the book Embedded Linux primer says

Notice that the process called hello thinks it is executing somewhere in high RAM just above the 256MB boundary (0x10000418). Notice also that the stack address is roughly halfway into a 32-bit address space, well beyond our 256MB of RAM (0x7ff8ebb0). How can this be? DRAM is usually contiguous in systems like these. To the casual observer, it appears that we have nearly 2GB of DRAM available for our use. These virtual addresses were assigned by the kernel and are backed by physical RAM somewhere within the 256MB range of available memory on the Yosemite board.

I have attached Code and output relating to above statement.

I want to understand how 32 bit addressing translates to 2GB of memory. Is each address consists of 4 bits of memory then 0 to 0xFFFFFFFF translates to 2GB of memory.

Calculation: 0XFFFFFFFF in decimal is 4294967295. 4 bits per address . i.e (4294967295*4)/8 = 2147483647.5 bytes = 2.1 GB

  1. Am i correct that each address can hold 4 bits of memory?
  2. How is this bits per address decided?

Thanks

CodeOutput

soul z
  • 1
  • Please don't post pictures of text – Chris Davies Jul 05 '22 at 06:44
  • 1
    You've tagged with [tag:virtual-memory]. Have you read anything on this subject yet? – Chris Davies Jul 05 '22 at 06:48
  • @roaima yes. thats what the topic from the book was covering. Im sorry if the question feels useless. I have just started learning embedded systems – soul z Jul 05 '22 at 06:52
  • if you're on a PC, or pretty much any other mainstream computer, your memory is going to be byte-addressable, so 8 bits per byte, 8 bits per memory address. (In the low level, the processor may load bigger slices at once, but that's invisible to the program code. Specialized processors, like DSPs might have the smallest addressable unit larger than a byte. I'm not sure how it was on e.g. Sparc and Alpha, but they're kinda dead too.) – ilkkachu Jul 05 '22 at 08:49
  • If the book doesn't say where it pulled the 2 GB limit from, it's not a very good one. Though they might have mentioned it at an earlier point, and expect you to remember. It's relatively common for OSs to split the memory space to a kernel area and a userland area, so the OS gets to keep its own toys in memory in unchanging addresses all the time. 32-bit Linux used a 3/1 split, but I think I've heard mentions that Windows used a 2/2-split. Not that your quote says anything about Linux, or what book it was, so we don't know if it was Linux. – ilkkachu Jul 05 '22 at 08:53
  • I suggest you read something about what an MMU (memory management unit) in a CPU or memory controller does (translation of virtual vs. physical memory). That should help you refine your question, so we understand what you want to know. – Philippos Jul 05 '22 at 09:57
  • @ilkkachu That's outside the question's scope, but please note that there are special cases where byte-addressing does indeed have visible impact on the program code, one example being jumps to odd addresses on ARM cores, leading to a jump to the even address while switching from the ARM instruction set to thumb instruction set. – Philippos Jul 05 '22 at 10:05
  • @Philippos, hehe, somehow I find that quirk amusing. Anyway, that's somewhat similar to alignment restrictions for data, e.g. that some CPUs don't allow accessing unaligned 16/32/64-bit values. Which doesn't mean arbitrary byte accesses wouldn't be available and actually, if the memory was addressed by e.g. 16-bit words, there wouldn't be unaligned 16-bit accesses. – ilkkachu Jul 05 '22 at 10:48
  • Hi. The book is embedded linux primer. So it is regarding linux – soul z Jul 05 '22 at 10:50
  • @Philippos, Okay . I will learn about MMU and tranlation. Thanks – soul z Jul 05 '22 at 11:04

0 Answers0