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

Michael Clark michaeljclark at mac.com
Thu Jul 14 00:31:57 BST 2016


WebAssembly is not designed for server side OS ABI JIT. Intel Pin for RISC-V is closer to what I'm looking for. Easy JIT on the client is not my end goal. I want to exploit the bit complexity and may swizzle new ISAs on the fly. Currently working on a BMI2 PEXT/PDEP codec for RISC-V. I need 112 bits of ABI entropy for my application.

Sent from my iPhone

> On 14/07/2016, at 4:38 AM, Samuel Falvo II <sam.falvo at gmail.com> wrote:
> 
> 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.
> 
> -- 
> 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/CAEz%3Dso%3DcACz8GEoa4k_%2B%2BDRq9e35QqdYU_%3DPkWZcXqWkL-9D2Q%40mail.gmail.com.


More information about the lowrisc-dev mailing list