[lowrisc-dev] Re: [sw-dev] Is a de facto standard memory map helpful or harmful?

Michael Clark michaeljclark at mac.com
Wed Jul 13 16:55:57 BST 2016


Yes a standard memory map is harmful on reflection.

This could be solved with in-kernel JIT perhaps? I'm curious. I will dig deeper and may take a look at the ARM virt_to_phys and phys_to_virt patching (we don't like patching and self modifying code). RISC-V doesn't have large immediates as the maximum is 20-bits. Someone wise must have decided this.

I'm looking at binary translation. Absolute references make things much harder for static translation (as we can't easily distinguish between constants and addresses). I'm investigating how much RISC-V can be statically translated and am having some initial success with a tiny hello world and the tiny newlib crt.

A target that can be statically translated is attractive for many reasons.

If we had some constraints in the compiler such that LUI was used for constant building and AUIPC for address building it would make the ISA a much better virtual target (however I think I may have seen cases where LUI is used for both addresses and constants). The ELF structure helps although Linux does lots of interesting things with custom sections.

My feedback is that it would nice to be able to statically differentiate an integral from an address in the machine code. Of course there is a bootstrapping problem where one has to convert an initial set of constants into addresses.

If the ISA is a nice IR then we could JIT the kernel (and not do any patching). A -pie kernel. -pie should be de facto perhaps.

I'm sure someone wise has already thought this all through and I am picking this up via inference.

Sent from my iPhone

> On 14/07/2016, at 2:55 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
>> On Wednesday, July 13, 2016 3:03:59 PM CEST Alex Bradbury wrote:
>>> On 13 July 2016 at 14:38, Arnd Bergmann <arnd at arndb.de> wrote:
>>> The main problem for operating systems is to have the kernel run at
>>> a nonconstant physical address. On ARM Linux, we work around this by
>>> patching every call to phys_to_virt() and virt_to_phys() at early
>>> boot time as soon as we have detected the start of RAM.
>>> 
>>> This works fine for the most part, but there are a couple of downsides:
>>> 
>>> (snip)
>> 
>> Thanks for sharing your experience here Arnd - I'm glad someone with
>> considerable kernel experience has chimed in. Would having a CSR
>> (RISC-V control register) that contains the base physical address be
>> an effective solution to avoid the need for function patching?
> 
> The patching is done purely for performance reasons, the implementation
> of virt_to_phys() is expected to be a single instruction adding an
> immediate value on ARM rather than loading a global 32-bit variable and
> adding that.
> 
> This means using a CSR only helps if that makes it substantially faster
> than reading from cached memory.
> 
> I'm actually not convinced that there is much need for the patching
> to start with, the most common operations that need the translation
> (page table updates, DMA setup, task switching, ...) are not in the
> extreme hot path, and it may have been done just to ensure that there
> could not be a performance regression at the point when we started
> allowing a single kernel binary to run on variable RAM addresses.
> 
> Then again, all other architectures seem to use a constant value,
> so maybe the runtime overhead is bigger than I think.
> 
>    Arnd
> 
> -- 
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe at groups.riscv.org.
> To post to this group, send email to sw-dev at groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/15271183.bf2SjugNUD%40wuerfel.



More information about the lowrisc-dev mailing list