This page is a mirror of Tepples' nesdev forum mirror (URL TBD).

# Simple way to calculate memory size from address lines

Sometime ago I found a way to quickly know the size of a memory region from its address bus size, or anything that is about mapping bits to number of permutations, really. It's very, very stupid and simple, it's nothing ground breaking, and I'm pretty sure some smarty pants around here already know that "trick" since long ago, but I share this because 1) some people might find it handy, and 2) I want to know if someone already found it before or heard that somewhere else. Like I said, it's very simple, almost too obvious, but my colleagues, when I told them about that "trick", were like, "oh, that's interesting and useful actually, I didn't realize that before". So here is it:

How do you know, say, the number of bytes an N-bit address bus can address? Decompose N into tens and ones. The digit in the tens place corresponds to a SI suffix: 0 ⇒ (no suffix), 1 ⇒ kilo, 2 ⇒ mega, 3 ⇒ giga etc. and the digit in the ones place maps to a power of two from 1 to 512: 0 ⇒ 1, 1 ⇒ 2, 2 ⇒ 4, ..., 9 ⇒ 512; succinctly put, 2x, but you should know them by heart, which is long done for about all of you.

Example:
The x86_64 architecture has 64-bit registers which makes native integers and pointers 64 bits in size. However, in current implementations found in desktop computers, only 48 LSBs of the virtual address (and thus, of a pointer) are used. What it the size of this virtual addressing space? x86_64 can address bytes, so for 48 address bits, 8 ⇒ 256 and 4 ⇒ Tera, gives 256 TB.

Example:
How many address pins does a 8KB memory have (assuming a 8-bit data bus)? 13, because 10 is for kilo and log2(8) = 3.

Yeah, it feels a bit stupid to develop the reasoning of each example for something that simple, but it would otherwise looks kinda cheap of a post.
It's simpler than you think:

Memory size from bits: 2 to the [number of bits]th power
Bits from memory size: log2([memory size in bytes])
tokumaru wrote:
2 to the [number of bits]th power.

Exactly, but what my post is all about is calculating that in your head easily with an easy to use result, because I can tell 26 bits gives 64MB instantly, whereas I cannot tell it's 67108864 bytes as instantly, I would have to put out my cellphone or launch Guile/Python/Octave/bc etc.
Ah, OK.
I'd never thought of it quite like that -- the "tens-place defining the SI/unit that 2^ones-place-value essentially represents" concept, I mean. Huh, imagine that. Yes, I would say that's definitely clever! I'll try to remember it method for the future, assuming I can remember the "SI/unit suffix table" for the tens place (it's obviously in my head, I just have never assigned values to it, ex. 1=kilo, 2=mega, 3=giga, etc.).

Usually I just work it out backwards. For example, this is how I normally would have handled your "how many address lines are needed to address up to 8KBytes" question, doing it mainly in my head: "We know 16 bits is 64KB, so 15 is half that at 32KB, 14 is 16KB, 13 is 8KB. Thirteen." I tend to start with 16-bit probably because of my 65816 and (early-ish) x86 days.

Very rarely do I ever bother with math (re: log2(n)) unless it's a very large value. Your x64 48-bit example is one where I would. For that, this is what I'd have done: bust out a calculator, do 2^48, which gets me 281474976710656. From there add commas where appropriate (I tend to work from right-to left for this), so 281,474,976,710,656. Then again from right to left, working out what unit is based on that: "710KB... 976MB... 474GB... 281TB, or thereabouts".

OT: Then again I've always done certain kinds of math operations in a way that I would get chastised for by teachers. I have difficulty with the number numbers 7, 8, and 9 (and sometimes 6). The only exception is if they're of themselves, i.e. 7*7, 8+8, etc. I know without issue. It's when they're used with other 7-to-9 values that I have trouble. At some point I figured out on my own that I could just round up a value to an "easier" number, then subtract what I rounded up by later. Example: 17+8 for me becomes 20+8-3 thus 25. It's more work, but it's less taxing on my brain. Can't explain why, it just is. With multiplication, I vary. Example: 17*8 for me would become either (20*8)-(3*8) or (10*8)+(7*8). If I first thought of doing the 2nd method, I'd hit 7*8 and say "screw it", and instead use the 1st method, thus: 20*8=160, 3*8=24, 160-124=136.

I know this isn't efficient, even remotely, and my brain can't really handle doing anything past super basic math this way... but it's how I survived school. I need pen/paper otherwise. Here's the real kicker: if you asked me to do some basic math involving 7/8/9 without that method? I'd do what I could, then start adding additional numbers using my fingers as helpers and counting out loud. Yup, I'm 41 years old and still do this on occasion. The look on adult's faces is always the same: a smirk backed with an expression of horror, like "is he seriously counting on his fingers? Is this guy slow?" But I honestly couldn't care less -- use whatever tools you have. Kids, on the other hand, don't give me any grief.
For the math-inclined, it's easy to see why this method works. First, as tokumaru underlined, simply doing M = 2N gives the exact answer. By decomposing N into tens and ones, we effectively get the equivalent M = 2T·10 + O, which is M = 2T·10·2O. In this form, we can see that the tens will give you powers of 1024 (210¹ = 210 = 1024 = 1K, 210² = 210·2 = 1024 × 1024 = 1M etc.) that is multiplied by 2O.
koitsu wrote:
OT: Then again I've always done certain kinds of math operations in a way that I would get chastised for by teachers. I have difficulty with the number numbers 7, 8, and 9 (and sometimes 6). The only exception is if they're of themselves, i.e. 7*7, 8+8, etc. I know without issue. It's when they're used with other 7-to-9 values that I have trouble. At some point I figured out on my own that I could just round up a value to an "easier" number, then subtract what I rounded up by later. Example: 17+8 for me becomes 20+8-3 thus 25. It's more work, but it's less taxing on my brain. Can't explain why, it just is. With multiplication, I vary. Example: 17*8 for me would become either (20*8)-(3*8) or (10*8)+(7*8). If I first thought of doing the 2nd method, I'd hit 7*8 and say "screw it", and instead use the 1st method, thus: 20*8=160, 3*8=24, 160-124=136.

I know this isn't efficient, even remotely, and my brain can't really handle doing anything past super basic math this way... but it's how I survived school. I need pen/paper otherwise. Here's the real kicker: if you asked me to do some basic math involving 7/8/9 without that method? I'd do what I could, then start adding additional numbers using my fingers as helpers and counting out loud. Yup, I'm 41 years old and still do this on occasion. The look on adult's faces is always the same: a smirk backed with an expression of horror, like "is he seriously counting on his fingers? Is this guy slow?" But I honestly couldn't care less -- use whatever tools you have. Kids, on the other hand, don't give me any grief.

I guess we all have the "difficult" numbers, the ones we struggle with . I have no problem multiplying numbers, but sometimes, when the multiplicands are in the 7–9 range, my spontaneous result is wrong because I use the product from the wrong numbers (like doing 6×7 = 56, and then "oops, that's 42, 56 is 7×8"). The same thing happens with hex numbers, I tend to mentally mix up 0x0B and 0x0D, doing "0x0B = 13... oops, wrong one". And resistor color bands too, from yellow to blue ("green is 6... oops, wrong one"), though these days, I rarely see through-hole resistors, so it's much less of an issue. And for your technique of rounding a number to the "easiest" number then subtract, I do it all the time, and I don't see it as inefficient because I'm faster with that method, probably because it allows to "guesstimate" quickly and you deal with smaller/simpler numbers. From your example 17×8, I also do (20×8)-(3×8) but even before, I think "the result is under 160", which helps me check the result mentally should I mess up numbers.
koitsu wrote:
Yes, I would say that's definitely clever! I'll try to remember it method for the future, assuming I can remember the "SI/unit suffix table" for the tens place (it's obviously in my head, I just have never assigned values to it, ex. 1=kilo, 2=mega, 3=giga, etc.).

Usually I just work it out backwards. For example, this is how I normally would have handled your "how many address lines are needed to address up to 8KBytes" question, doing it mainly in my head: "We know 16 bits is 64KB, so 15 is half that at 32KB, 14 is 16KB, 13 is 8KB. Thirteen."

Ditto.