The Pi hardware (in common with all similar processors) does not support memory mapped IO in the way that, for example, an ARM Cortex M part does. This is because it is designed to work with DDRAM which is hard enough to get to work in the very special case of a processor or FPGA to memory interface - as far as I know no one uses the DDRAM interface for IO. The usual solution is to provide some additional IO ports which will require some kind of drivers to operate them - they are rarely mapped into normal memory space.
The PI has very limited IO (Beagles are much better) but it is supported by lots of low cost IO expanded boards from many sources but they are all slow.
To be fair the PI is not alone in having this problem - the best way to get data in and out of most computers at high speed is often to use Ethernet or PCI but both require serious hardware.
It's this (hardware) limitation which allows small Cortex M class micros to beat the ****** out of GHz application processors like that on the PI when it comes to low latency fast IO. And even with Gbit Ethernet, although you can get 100Mbytes/s in and out of the processor the round trip latency will be measured in us - perhaps 100x slower than an STM32F4xx can bit bang IO !!!
Roger is correct in implying that it isn't a compiler issue - you'll have the same problem with Python, C or anything else.
What are you trying to do - there are (almost) always ways round these problems.
You're not a processor architecture expert either. The 8086 processor and some of its more modern variants had special instructions for I/O operations
that separated them from memory space accesses using dedicated hardware I/O read/write signals (I assume that they still do, but for example the PCI bus
is memory mapped !). ARM processors (and most other RISC processors) do not have these instructions and instead dedicate some of their memory
space for I/O, this is what is known as memory-mapped I/O and accessing this "I/O space" uses the same instructions as normal memory reads and
writes. When this I/O space is accessed it does not in any way affect DRAM because the memory address decoding of this I/O space prevents RAM
access hardware signal pins from being activated.
ARM SoCs use some of it's memory space for I/O registers built into the SoC to perform the various types of I/O supported by the chip. While in general
these registers do use consecutive bits in each 32 bit word, unfortunately when they are connected to dedicated I/O pins on the SoC they do not always
follow that bit order. Most of the time it is because some of the GPIO pins have multiple functions and when the "alternate" function (such as I2C, SPI, A/D, etc)
is used it splits up the other I/O bits so that they are no longer 8 or 16 consecutive bits. Sometimes because of pin limitations they just don't run all of the bits
to external pins. And just to make things worse, sometimes when laying out the PCB, it is just easier to route the SoC I/O pins to the PCB I/O when they are
split up. This has always been a pet peeve to me for the reason that Michael Vos has stated, sometimes it would just be a whole lot better/easier to be able
to do true byte-wide (or bigger !) accesses but it is physically impossible.
You're not a processor architecture expert either. The 8086 processor and some of its more modern variants had special instructions for I/O operations
that separated them from memory space accesses using dedicated hardware I/O read/write signals (I assume that they still do, but for example the PCI bus
is memory mapped !). ARM processors (and most other RISC processors) do not have these instructions and instead dedicate some of their memory
space for I/O, this is what is known as memory-mapped I/O and accessing this "I/O space" uses the same instructions as normal memory reads and
writes. When this I/O space is accessed it does not in any way affect DRAM because the memory address decoding of this I/O space prevents RAM
access hardware signal pins from being activated.
ARM SoCs use some of it's memory space for I/O registers built into the SoC to perform the various types of I/O supported by the chip. While in general
these registers do use consecutive bits in each 32 bit word, unfortunately when they are connected to dedicated I/O pins on the SoC they do not always
follow that bit order. Most of the time it is because some of the GPIO pins have multiple functions and when the "alternate" function (such as I2C, SPI, A/D, etc)
is used it splits up the other I/O bits so that they are no longer 8 or 16 consecutive bits. Sometimes because of pin limitations they just don't run all of the bits
to external pins. And just to make things worse, sometimes when laying out the PCB, it is just easier to route the SoC I/O pins to the PCB I/O when they are
split up. This has always been a pet peeve to me for the reason that Michael Vos has stated, sometimes it would just be a whole lot better/easier to be able
to do true byte-wide (or bigger !) accesses but it is physically impossible.
Gary, one little addition: the PCI bus allows IO accesses that the '8086 family of processors support. Most expansion cards no longer use such old fashioned stuff, but the PCI bus supports it. A reason could be that the address space on IO accesses is only 64k.
Gary, when someone start a reply with an "I'm not an X expert but I'll try to help" any rational person interprets this as a genuine attempt to set the context for their answer.
To respond with an " You're not a Y expert either ..." is quite simply rude and unhelpful. No, I'm not a processor architecture expert and I never claimed to be.
My reply was, perhaps, a bit of an over simplification and I had assumed that the OP wished to connect an external non-memory device to the PI and have it appear in the PI memory space - something which is easily done with ARM Cortex M (and similar) parts with external memory buses but not feasible on most application processors.
I'm familiar with the "embedded" family of STM32 processors. On those, you need to go quite far up the ranks of processors before they start having enough pins that ST decided to implement the external memory bus.
Similarly, MOST application processors have an external memory bus. Simply because integrating 1Gb of memory onto one or two chips is best left to the companies specializing in memory chips. That said... the DRAM bus is special and will you be able to access other stuff? The answer is usually yes. Those external busses often need to interface to NAND flash, SD cards (or EMMC) and stuff like that.
The one exception that I'm aware of is the BCM2835. Because it has the memory bus broken out on the TOP of the chip for the stacked memory arrangement, that's one of the few "application processor" chips that doesn't have an external memory bus.
