The offsets are determined by how your own HDL code uses the 'address' values passed to it. If your custom component is defined to have 4 address bits then your hardware can respond to reads/writes to 16 different address offsets from your base address. Using the native versions of IORD/IOWR, if your C code does an IORD(HASH_BLOCK_BASE, 5) for example, then the value of 'address' placed on the Avalon inputs to your logic will be 5 (and as far as your HDL is concerned the base address is irrelevant). Only you know what your logic places on the readdata port at a particular address offset, so as such you define the registers.
To try and answer the second part of your question; read, readdata etc are not registers that you can read and write. For example, the following line of code:
IOWR(HASH_BLOCK_BASE, 8, 1);
causes the Avalon switch fabric to place 8 on the 'address' port, 1 on the 'writedata' port and then strobe the 'write' port. Your HDL has to use these signals to latch the data into a register, or maybe just trigger some action. Your HDL is unaware of its base address; that's just there to tell Avalon which slave port it's talking to.
Likewise:
IORD(HASH_BLOCK_BASE, 3);
causes the Avalon switch fabric to place 3 on the 'address' port, strobe the 'read' port and latch whatever your HDL has placed on the readdata port.
It's also important to note that the 'Avalon switch fabric' isn't like a normal shared bus where a device has to tri-state its ouputs when not selected. It seems to behave more like a big multiplexer, so in a lot of cases you don't really need to worry about the 'read' signal if you can be sure that for any value of the address input your readdata output is always ready. For more complex situations you can start implementing wait states, latency etc.
I hope this goes some way to clarifying things. Once you cracked the concept, it's a thing of beauty.
Good luck