When the CPU wants to do calculations and mess with I/O stuff, does the I/O always load into the RAM first? Or is it possible for I/O to be directly computed if needed and skip RAM?
>>53672068
>Liking daft punk
>>53672068
typically with x86 certain ranges of memory ARE the io
http://wiki.osdev.org/I/O_Ports#The_list
>>53672113
>implying I don't think daft punk is shit
>>53672130
Then why would you post about their ram album here?
>>53672194
I haven't complained about how disappointing that shit album was for a few years, I needed to get it off my chest again.
>>53672121
thank you for the informative response anon.
So does EVERYTHING that pass into or out of the CPU go straight to or through RAM?
>>53672212
She's up all night to the sun, I'm up all night to get some
She's up all night for good fun, I'm up all night to get lucky
>>53672289
Typically everything goes from the storage devices, to the RAM, then to the CPU cache.
Sometimes, with clever IO management in motherboards/chipsets, data can be stored in IO cache and be retrieved by the CPU from the data cache between main memory and the CPU cache.
If it's memory mapped i/o, it's possible.
But basically, any processing must be done in memory (or register), unless it's DMA.
>>53672289
DMA allows other devices to move data into and out of RAM while the CPU does other things.
>>53672068
Look up IOMMU.
The input has to come from somewhere, and the output has to go somewhere. The keyboard keys map to memory, the display is mapped to memory before being printed to the screen, etc. They build special ALUs (arithmetic logic units) to do repeated calculations and throw them in processors to make them faster, but you have to pick and choose what components exactly you want squeezed into the finite cpu space.
>>53672312
Interesting, but isn't the I/O cache you mentioned essentially a specialized kind of RAM?
So is it right to say that the actual ALU is always encompassed by some type of memory? No kinds of exceptions?
>>53672393
The cache is more like an integrated controller with extra fast memory. It's not RAM, because it's not random access.
>>53672429
>>53672382
>>53672312
thank you for explaining bros, this stuff is so fucking fascinating and intricate.
So isn't cache just fast as fuck ram that intelligently chooses what to keep around?
I understand ram is "random access", so does that imply that you cant pick out any random piece of info located on the CPU cache?
I'm willing to dig into whatever you guys have to offer.
>>53672631
The cache simply stores data before it hits the CPU. If that data is required again, before it gets written over or flushed, then the cache can just hand it to the CPU without having to re-retrieve it.
>>53672761
so the cache doesn't choose to prioritize by what the CPU thinks it will need in the future? It's really a matter of storing histories of the last operations in case it's needed again?
I was under the impression that the low level cache's predicted as to what the upcoming operations would or might include and kept those. It's probably a combination of both, i'm sure.
>>53672859
Don't your textbooks already explain all this?
>>53672894
Yeah I learned a lot of this stuff a few years back in college. I forgot a ton of it, just trying to refresh my memory on the logistics between the components purely because I find this stuff interesting as fuck. It's almost a crime how much abstraction hides all of the sublime and stunning feats of engineering in modern computers.
>what is DMA
>>53672299
How can one album be such a cheesy flop.
