# How big variables are stored in RAM memory?

I've just made a simple RAM memory in Minecraft (with redstone), with 4 bits for the address and 4 bits stored in each cell. Our next goal is to store different kinds of variables in it and to process them differently.

We are not engineers, so we really know nothing, but we have already made some quite complex things and we think we can do this. The problem is that we can't figure out how to store variables of more bits than can be stored in a single cell. I'll give an example.

Think of a 16-bit variable. We thought that there would be no sense in creating such big cells, so we decided to store that data by storing 4 bits in each cell. But that's not enough, we have to relate those 4 cells to each other. So we thought that we had to create 8-bit cells, with 4 bits of content and 4 bits to store the address where the next 4 bits of the variable are stored. However, 4 bits of address is nothing for a RAM memory, we can't store anything there. So we would need at least 8 bits for the address. 4 bits of content also seams quite low, and we also need at least another 4 bits to store the type of the variable.

Well, finally we thought that that technique was absurd and that it wouldn't be done like that in real life. And we don't know how to do it now. I've searched on the web about how RAM memory works and the few pages that I've found were too complex for our needs. Could someone please explain to us how this is done in real life and how we can apply it in redstone?

• It would help to get someone more fluent with English to help you write posts here. The double negatives and unusual word usage makes your post confusing. Also, you can't expect everyone to know what Minecraft and Redstone are. If they are relevant to your question, explain them. If not, leave them out to avoid confusion. Oct 25, 2012 at 16:37
• Unless you're creating a Lisp Machine, you don't normally store the type of the variable in memory with the variable. Your software just knows to expect a certain type to be stored at that location. And you don't normally store an address to the rest of the data, you just put the pieces in contiguous locations, as explained in Olin's answer. Oct 25, 2012 at 16:54
• Which Redstone do you mean? minecraftwiki.net/wiki/Redstone_(disambiguation) Oct 25, 2012 at 19:12
• What happens if you copy/paste that RAM block and connect the new block to the same data bus as the previous one? What happens when you increase the data bus width? Those are indeed the problems that computer designers dealt with, long time ago. Search for address decoding or similar topics. Aug 2, 2015 at 16:32

It's not clear what you are really asking, but it is common to store binary values that are wider than the addressable unit of memory. For example, if you want to store 16 bit words in a byte-addressed memory, then you use two bytes. That also means the software has to know which byte is stored first.

In your case you seem to have native 4 bit words. To store a 16 bit value, use 4 words. Again, your software will have to know what convention you are using, like low word first or high word first.

Since your memory only has 4 address lines, its size is limited to 16 native words. Your native word size appears to be 4 bits, so your memory can hold only 64 bits. That means it will be completely used up by two 32 bit values or four 16 bit values, for example.

There are three common approaches for storing items larger than one memory chunk. Assuming memory is 16x4 (as in your example), one approach would be to specify that 8-bit values are stored in one of eight pairs of registers (the top three bits select a pair, and the bottom bit identifies a register within the pair), and 16-bit values are stored in one of four quartets. A second approach is to specify that any group of two or four consecutive registers may regarded as a longer register. The third approach is to separately specify the address of the upper and lower portions of the composite register.

The first approach is simple from a hardware standpoint, and has that advantage that fewer bits are needed to select a longer register than a short one (thus freeing up opcode bits). The second approach makes things a little nicer from a programming standpoint, but requires the ability to perform an address increment, with carry propagation, between fetches. The third approach is nice from a software standpoint, but requires specifying twice as many addressing bits as the first one.

Maybe this will help. In real life you can buy memory arranged in all different ways, and you could make one anyway you wanted. But lets talk about your memory, you've made it 4 bits wide which in real life would be a bit of pain unless you put two side by side to make 8 bits since most things like to operate in bytes (8 bits) and not nibbles (4 bits). So lets talk 8 bits to be clearer.

## Real memory

Now I can buy an 8 bit memory part that say held 256 Bytes of memory. Think of 256 of your new 8 bit blocks stacked on top of each other. Each one of those blocks has an address, for simplicity well say they are address 0-255. Now whenever you want one of those values stored in memory you simply ask for the memory at block 124.