Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Request for clarifications regarding hardware capabilities for shared mappings

Đang mở
  • Có gì không ổn?
#7 9 bình luận 1 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
30/100
Loại issue
Tài liệu
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
wasm
Lĩnh vực
documentation, embedded-iot

Hướng nghiên cứu

Đọc Target_Platforms/Embedded-SIG-Target-Platforms.md, đặc biệt là phần hỗ trợ MMU/MPU, và so sánh các giả định trong đó với vấn đề về shared mappings được WebAssembly memory-control/#19 nêu ra. Được coi là hoàn tất khi đã ghi lại liệu các shared mappings hữu hạn có được hỗ trợ trên các MPU mục tiêu hay không, hoặc ghi lại quyết định yêu cầu một MMU baseline.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

In the target platforms doc, there is a section explaining that the E-SIG feels comfortable assuming an MPU or MMU for efficient implementations. This is very helpful since it gives us a baseline of memory-related hardware capabilities that we can assume when considering implementations strategies for various features.

Just to state some assumptions to see if I'm understanding these terms correctly so folks can correct me if I'm wrong:

  • an MMU includes some sort of page table for mapping virtual addresses to physical addresses allowing page-granularity control over both access-rights as well as sharing (where multiple virtual addresses map to the same physical address);
  • an MPU includes a finite set of protection registers that can be used to configure at runtime access-rights for a finite set of address ranges.

Based on these assumptions, one corollary is that any feature that requires fine-grained/page-level control over an unbounded set of memory ranges wouldn't work on an MPU and thus would not work across all the target platforms.

But one thing that's unclear to me is whether an MPU allows mapping a finite set of distinct "virtual" addresses to the same "physical" page of RAM. Hypothetically, it seems like an MPU could do this without blowing its limited hardware budget by including an "offset" field in its per-region configuration state that was added as part of address translation. With this hardware capability, we could, e.g., efficiently support a small finite number of "mmap()s" (or features that want to be implemented in terms of mmap()). However, scanning the docs of the popular ARM Cortex-M MPU, it seems like at least this one popular MPU can't do such shared mappings. However, I've also heard that various extensions outside the official ARM Cortex-M MPU extension might allow this? Also, I have no idea about the wider world of MPUs.

So, what I'd love to get a clarification on (here and, ideally, in the doc) is whether the E-SIG believes that such shared mappings are indeed possible across the target platforms' MPUs or perhaps whether we want to raise the baseline to assume an MMU.

One discussion where this is concretely relevant is in the WebAssembly CG memory-control proposal (and its collection of sub-proposals), e.g., memory-control/#19, which does seem to assume an MMU.

Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
15
Fork
5
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của bytecodealliance/sig-embedded

Tất cả issue của bytecodealliance/sig-embedded

Issue tương tự

Thêm issue về Documentation

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.