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

Samuel Falvo II sam.falvo at gmail.com
Wed Jul 13 17:38:02 BST 2016


For JITing purposes, I'd look to use WebAssembly instead of the ISA as-is.
It's designed just for this purpose.
On Jul 13, 2016 8:56 AM, "Michael Clark" <michaeljclark at mac.com> wrote:

> 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
> .
>
> --
> 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/C1F2D228-FE12-4F30-A8BF-60C4CEFFC352%40mac.com
> .
>


More information about the lowrisc-dev mailing list