hard drive - How is HDDM (not RAM!) accessed, modified and addressed in modern computers?

20
2014-01
  • Mark Miller

    Warning: yeah, I know that article of Wikipedia. It's just too difficult for me! I hope that there is some person who could explain it more simply...


    Background: I designed a 6-bit computer. It has 4kB of RAM and 4kB of ROM (uses double address). Both are accessed and read the same way like the other one:

    1. 12-bit address goes to a decoder.
    2. Decoder decodes which memory cell should be accessed.
    3. Memory cell is accessed and its contents go to register A.

    Both are strictly limited. Now we got a modern 32-bit computer. It has:

    • 4 GB of RAM. Limited.
    • 1 TB of HDDM, that can be expanded just by using bigger HDD or more HDDs!

    Everything is clear with RAM - it is read and modified the same way like the one on my computer. But how do we access HDDM?

    • Do we have to include a HUGE decoder into the hardware of a modern computer to be able to address a HUGE quantity of separate memory cells? But still, HDD memory should be still limited to a certain amount of memory?
    • Or maybe there are tiny magnetic disks that are turning around very quickly, with each memory cell emmiting its own address, and little scanners waiting for the disks to turn into a right position to scan? But is that speed really possible?

    Generally: so how we are able to have unlimited amounts of HDDM? How is HDDM accessed, read and modified?

    Extra: is SSDM accessed with a decoder, so that is why it's faster than HDDM?

    • Answers
  • Mokubai

    For devices that are not directly addressed you do not have to give them a specific address using a fixed number of lines, many devices allow you to send multiple bytes describing the address you want them to access. Storage devices do not generally have address lines connected to them and so implement a command bus that allows you to send a set of bytes similar to the following:

    1. 1st byte: "I want to read something, the next 6 bytes you receive will be the address to read from"
    2. 2nd byte: Address byte 1
    3. 3rd byte: Address byte 2
    4. 4th byte: Address byte 3
    5. 5th byte: Address byte 4
    6. 6th byte: Address byte 5
    7. 7th byte: Address byte 6

    They will then go away and some time later will start the process of sending you bytes of data found at that address.

    You can also redefine the base quantity of "one block" of data to be something other than a single byte (as memory uses). So at address 0 is a 512 byte block, at address 1 is the next 512 byte block and so on.

    Hard drives and so on use both these methods. What you need to research is called Logical Block Addressing

    This still suffers similar problems to the one we had when changing from 32 to 64-bit processors, the old hardware had to be replaced as it could not physically support the new interface and addressing scheme. Previous generations of hard drive interface only supported up to 137GiB of storage with a 28-bit block address and newer interfaces support 48-bit addressing which allows addressing up to 128 PiB.

    Both the controller and slave device have to be able to talk using the newer standard in order for them support the larger size, if one of them simply cannot send all the required information then it will need to somehow be replaced.


    • Related Question

    memory - How does the CPU write infomation to ram?
  • Questioner

    My question is, how does the CPU write data to ram?

    From what I understand, modern CPU's use different levels of cache to speed up ram access. The RAM gets a command for information and then sends a burst of data to the CPU which stores the required data (and a bunch of extra data that was close to the address the CPU wanted) into the highest level cache, the CPU then progressively asks the different caches to send smaller and smaller chunks of data down the levels of caches until it is in the level 1 cache which then gets read directly into a CPU register.

    How does this process work when the CPU writes to memory? Does the computer go backwards down the levels of cache (in reverse order as compared to read)? If so, what about synchronizing the information in the different caches with the main memory? Also, how is the speed of a write operation compared to a read one? What happens if I'm continuously writing to RAM, such as in the case of a bucket sort?

    Thanks in advance,

    -Faken

    Edit: I still haven't really gotten an answer which I can fully accept. I want to know especially about the synchronization part of the RAM write. I know that we write to the L1 cache directly from CPU and that data gets pushed down the cache levels as we synchronize the different levels of caches and eventually the main RAM gets synchronized with the highest tier cache. However, what i would like to know is WHEN do caches synchronize and scynocronize with main RAM and how fast are their speeds in relation to read commands.


    • Related Answers
  • Skizz

    Ah, this is one of those simple questions that have really complex answers. The simple answer is, well, it depends on how the write was done and what sort of caching there is. Here's a useful primer on how caches work.

    CPUs can write data in various ways. Without any caching, the data is stored in memory straightaway and the CPU waits for the write to complete. With caching, the CPU usually stores data in program order, i.e. if the program writes to address A then address B then the memory A will be written to before memory B, regardless of the caching. The caching only affects when the physical memory is updated, and this depends on the type of caching used (see the above link). Some CPUs can also store data non-temporally, that is, the writes can be re-ordered to make the most of memory bandwidth. So, writing to A, then B, then (A+1) could be reorderd to writing to A then A+1 in a single burst, then B.

    Another complication is when more than one CPU is present. Depending on the way the system is designed, writes by one CPU won't be seen by other CPUs because the data is still in the first CPUs cache (the cache is dirty). In multiple CPU systems, making each CPU's cache match what is in physical memory is termed cache consistancy. There are various ways this can be acheived.

    Of course, the above is geared towards Pentium processors. Other processors can do things in other ways. Take, for example, the PS3's Cell processor. The basic architecture of a Cell CPU is one PowerPC core with several Cell cores (on the PS3 there are eight cells one of which is always disabled to improve yields). Each cell has its own local memory, sort of an L1 cache which is never written to system RAM. Data can be transferred between this local RAM and system RAM using DMA (Direct Memory Access) transfers. The cell can access system RAM and the RAM of other cells using what appears to be normal reads and writes but this just triggers a DMA transfer (so it's slow and really should be avoided). The idea behind this system is that the game is not just one program, but many smaller programs that combine to do the same thing (if you know *nix then it's like piping command line programs to achieve more complex tasks).

    To sum up, writing to RAM used to be really simple in the days when CPU speed matched RAM speed, but as CPU speed increased and caches were introduced, the process became more complex with many different methods.

    Skizz

  • Am1rr3zA

    yes it's go backwards down the levels of cache and save to memory but the important note is in Multi Processing system the cache are shared between 2 or more processor(core) and the data must be consistent this was done by make shared cache for all multiprocessor or different cache but save consistency by use of Critical section (if data in one cache changed it force it to write in memory and update other cache)