6

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 don't really know nothing, but we have made already some quite complex things and we think we can do this. The problem is that we can't figure out how to store variables that of more bits that can be stored in a single cell. I'll give an example.

Think of a 16 bit variable. We thought that there's no sense in creating so big cells so we decided to store that data storing 4 bits in each cell. But that's not enough, we had to relate that 4 cells. 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 seems quite low, and we also need at least other 4 bits to store the type of the variable.

Well, finally we thought that that technique was absurd and that it couldn'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 the RAM memory works and the few that I've find was too complex for our needs. Could someone please explain us how this is done in real life and how we can apply it to redstone?

3
  • 4
    Here at Arqade, we can probably tell you how to do it with redstone, but how RAM works is probably outside our scope. That sounds like something that you need to spend some time researching yourself.
    – Frank
    Commented Oct 25, 2012 at 16:44
  • Data that a CPU operates on are not stored in RAM, but in "registers". One or more instructions fetch it from RAM to the register (the instruction is given the address, so you can fetch pieces from multiple locations if necessary, doing a bitwise shift in between). Registers are as large as the CPU design needs them to be, and might well exceed the width of a what can be stored in a single RAM address location. A CPU typically has a handful of registers. Operating directly on RAM contents is going to give you massive design headaches. Look up "CPU architecture" for how to design this stuff. Commented Feb 28, 2013 at 4:47
  • I'm voting to close because this is a question about how to design a CPU's memory architecture, which is off-topic. It's not about how to implement a design in redstone. The answers are all CPU architecture answers with only incidental mentions of redstone, which underlines that the real core of the question belongs under StackOverflow's cpu-architecture tag. Commented Mar 9, 2013 at 17:24

3 Answers 3

5

While going over how memory works in real life is pretty out of scope for Arqade, rather than chaining memory cells together, you could use a set number of cells for the address and the rest for the data.

So let's say you have 16 8-bit memory cells, and you want to store 16-bit values. Your current solution would be something like this:

# Value NextAdr
0 0000  0001
1 1111  0010
2 0100  0011
3 1111  0000

And so on, meaning for every 16 bits of data you want to store, you have to allocate 32 bits of cells. Instead, use the first cell to specify the two parts of the 16 bit value:

# Addr1 Addr2
0 0001  0010

# Value
1 11110010
2 01000011

Which would only require 24 bits of allocation per 16 bits of data.

You could further improve the efficiency by allocating one static 8-bit cell as a pointer. So, given 16 8-bit memory cells, you could hold 14 16-bit values, with an extra 8-bit cell left over.

Value 1:
Cell 0: 11110000 Cell 1: 01010101

Value 2:
Cell 2: 11110000 Cell 3: 01010101

# Access Value 1
Pointer cell: 0000 0001

# Access Value 2
Pointer cell: 0010 0011

Doing it this way is also scalable. If you need 32-bit values or 32 8-bit cells, assign two 8-bit cells as a pointer; 64-bit values or 64 8-bit cells, assign three cells as a pointer; and so on.

You could save even more space by making assumptions about where the parts of the value are stored. If, for example, the first part of the value is always proceeded by the second half, you don't need to keep track of the second half's address, cutting the pointer size in half:

Value 1:
Cell 0: 11110000 Cell 1: 01010101

Value 2:
Cell 2: 11110000 Cell 3: 01010101

# Access Value 1
Pointer cell: 0000

# Access Value 2
Pointer cell: 0010

Real world memory is a little more complicated than this, but it follows the same principles, and it should give you a good idea of how to improve your memory storage.

0

sounds like you need to store more than you can hold, try a 16 bit CPU (16 per cell) with 4 bits allocated as op code (16 functions decoded), 1 bit for a # (data / address storage multiplexer), and the remaining 11 bits as possable data entry, giving either a storage value up to 121, OR a value to controll one of 121 data cells or (bytes)

0

In a real computer, values larger than one addressable memory cell are stored in adjacent memory cells. That is, if you have a 16-bit value to store in your 4-bits-per-cell memory, you store it in 4 cells, perhaps with addresses 0100, 0101, 0110, 0111.

This means that you do not need to store any extra pointers (addresses); the memory is used efficiently. All you need to do to fetch the entire value is to fetch one cell and increment the address, four times.

Also note that "value followed by address of the next part" is a common data structure known as a linked list. It's quite useful for some purposes, but in this case is a waste.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.