POV-Ray : Newsgroups : povray.off-topic : Memory-mapped I/O : Re: Memory-mapped I/O Server Time
6 Oct 2024 06:05:28 EDT (-0400)
  Re: Memory-mapped I/O  
From: clipka
Date: 5 Feb 2015 07:25:02
Message: <54d3611e$1@news.povray.org>
Am 05.02.2015 um 09:33 schrieb Orchid Win7 v1:

>> As for the sound card, IIRC traditionally it was not memory-mapped. You
>> see, the sound card operates sequentially on non-repeating data, which
>> is exactly the mode of operation the DMA controller was designed for, so
>> to save memory address space for true memory (including devices' ROMs,
>> which are always memory-mapped) the card would present only two I/O
>> addresses for data (one for reading, one for writing). Same for disk I/O.
>
> Intriguing... I didn't know you could do that.

It's actually a quite simple mechanism, at least in basic theory. The 
idea is that the CPU has an input telling it to stall any bus access for 
a moment; the DMA asserts this signal to take over the bus for one 
memory access and another I/O access, then releases the bus again. The 
DMA controller in turn has an input by which the device hardware can 
signal that it is ready to transfer the next byte.

This was great stuff especially in the times when memory could go a good 
deal faster than the CPU could make use of it.

Well, things have changed: Memory access is the biggest bottleneck of 
all now.

>> If you really want to go down to that level, I'd suggest getting a
>> Raspberry PI and trying to write some standalone application (i.e. one
>> that doesn't need an OS) to run on it. The hardware seems to be well
>> enough documented to pull off that stunt.
>
> Or just, you know, the Pi emulator, which doesn't cost money. ;-)

Because a Raspberry Pi is soooooo extraordinarily expensive, sure... :P

Drawback of the Pi emulator is that it doesn't come with all those neat 
I/O pins ;)

>> And no, you don't need to tell the PCIe controller anything about this -
>> unless you're an OS developer and want to place the window somewhere
>> else in the physical CPU address space.
>
> So aside from assigning memory mappings, PCIe is transparent to the CPU.
> (?)

Memory mappings, IRQ mappings, I/O mappings, assignment of number of 
PCIe lanes... But yes - that's the gist of it.

> So, again, the PCIe bus from the CPU to the PATA / SATA / USB / FireWire
> / whatever controller is transparent, but USB itself isn't transparent,
> and you still need to know how to build ATA commands or whatever. (?)

Yup.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.