[arch] Apps memory independent to underlying memory layout

[ddrcode]

It comes from idea that apps should be transferable between platforms without the need of recompilation.
One of the major issue here is that RAM on various devices is located in different address ranges, so the unification can be dane with virtual addressing. Having that, could also be a good base for any form of multitasking, but this is not a concern of this story.

This proposal includes

• finding the good address range and memory size for the apps (or rather - for an individual app)
• expanding a system to do necessary address translation

First, the decision would need to be made in terms of address translation method. THe options are

1. Virtual memory and paging. The most complete solution and and it's fitting RISC-V features and philosophy, but paging may have its impact on overall performance. On top of that, it will require introduction of supervisor mode (as proposed in [arch] Introduce Supervisor-mode (S) #42 )
2. Position-Independent Code (PIC) - the option uses relative addressing only, so it's not fixed to any specific memory region. This technique is common for dynamic libraries, but can be used by apps as well. It requires the code to be compiled with a fPIC flag, and - on top of that - it requires GOT (global offset table) for data access.
3. Custom loader - in this scenario the system, while loading the app, adjusts the binary and corrects the addresses accordingly. If the code is compiled with -Wl,-emit-relocs, the relocs table could be used for adjusting the code.

[ddrcode]

It feels like option 3 is too hacky. I'd suggest to start with PIC (option 2), as it feels easy to implement and (optionally) migrate to option 1. At this stage the priority feels rather low, as 2 of 3 supported machines (virt and sifive_u) use the same memory space. The third one (sifive_e) has no means of loading the apps atm anyway. So the natural timeline would be

• block device driver to provide sifive_e an option to load apps
• PIC (this story)
• (optionally) S-mode
• (optionally) virtual memory