Python & Variables + Confusion About Memory Addresses

Variables like in the previous article are names that represent a value stored in memory. So if we have variable, alpha and “I am human” in memory address id1009 then alpha represents id1009 which contains “I am human”.

So that’s simple. I got curious at this point wondering how memory addresses are actually written and what is the max number of memory addresses available. I’ll talk about that after the variables section.

Variable Rules

Something I learned is when an expression is assigned to a variable it’s first evaluated. I knew the variable would return the result but I didn’t know it was evaluated before being assigned.

If you write this: huge = 56 * 9–12 + 6 it does this:

huge = 504 - 12 + 6 <- Evaluation <- Stores value in a memory address
huge = 492 + 6 <- Evaluation <- Stores value in a memory address
huge = 498 <- Assignment <- Stores memory address in variable

As for legal variable names. This I figured out because of all the times I did this when I first started.

The two rules are:

• variables must begin with an alphanumeric characters (a-zA-Z),
• variables must only contain alphanumeric (a-Z), digit (0–9) and underscores (_).

There are a few naming conventions that should be followed.

• Don’t use lowercase L, uppercase I or uppercase O. The first two can be easily mistaken for the digit 1 depending on the font and the third for zero for the same reason.
• Spaces in variables should be filled in with _, such as human_readable or i_am_me. Apparently this is called pothole case. It’s a weird name, but I understand the reference.
• Use lowercase letters.
• Avoid using camelcase or mixed case, CamelCaseExample and mixedCaseExample.

Now, that DOESN’T mean you can’t break those rules, those are just conventions. They come from PEP-8 which is basically the standard way of writing your program so it becomes understandable to most.

So that’s basically what I learned plus what I’ve also looked into to get more information. Nothing absolutely new to me but definitely would be helpful for someone looking for information about variables who stumble onto this article.

Memory Address Confusion

Memory addresses according to my understanding the number of memory addresses is 2 to the power of bits of a CPU. So then a 32bit CPU would have 4,294,967,296 memory addresses while a 64bit CPU would have 18,446,744,073,709,551,616 memory addresses. So just a little bit more.

I got that information from https://en.wikipedia.org/wiki/32-bit_computing#Range_for_storing_integers and https://en.wikipedia.org/wiki/64-bit_computing as well as CPU’s like Intel_80286 https://en.wikipedia.org/wiki/Intel_80286 and i386 https://en.wikipedia.org/wiki/I386 which showed the address width of each.

CPU Cache Holds Memory Addresses?

Now I’ve checked newer CPU’s and none had address with listed on the sidebar but they did have cache information there. Is cache what holds memory addresses these days? I ask because I looked at this image from https://en.wikipedia.org/wiki/CPU_cache.

This shows memory with index which I’m assuming is another way of saying memory addresses. So if I’m correct and cache does hold memory addresses then Ryzen 9 5950X would have:

Ln = [capacity] * [cores] = [memory addresses]
L1 Cache = 256,000 * 8 = 2,048,000 
L2 Cache = 4,096,000 * 8 = 32,768,000
L3 Cache = 4,096,000,000 * 8 = 32,768,000,000
Total Memory Addresses = 32,802,816,000

Hmm… So I feel like I’m wrong because a 64bit CPU has 8,446,744,073,709,551,616 but a Ryzen 9 5950X has 32,802,816,000?

Possibly Correct Now

Ha.. So I watched this video and it cleared up a lot.

A memory block contains the memory address which is a single byte within memory. So 8 bytes has 8 memory addresses. That means 32 MB has 32,000 memory addresses. If we look at the current RAM available we see 16 GB and 32 GB sticks being normal in workstations.

16 GB = 1,600,000,000 * 4 sticks = 6,400,000,000
32 GB = 3,200,000,000 * 4 sticks = 12,800,000,000

So.. is my thinking correct now? I definitely need more information in order to be sure.