Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Request for clarifications regarding hardware capabilities for shared mappings

Abierto
  • ¿Algo no está bien?
#7 9 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
wasm
Área
documentation, embedded-iot

Línea de trabajo

Lee Target_Platforms/Embedded-SIG-Target-Platforms.md, especialmente la sección sobre compatibilidad con MMU/MPU, y compara sus supuestos con la cuestión sobre mappings compartidos planteada por WebAssembly memory-control/#19. Se considera completado cuando se documente si los mappings compartidos finitos son compatibles con las MPU de destino, o se registre la decisión de requerir una baseline de MMU.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
15
Forks
5
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bytecodealliance/sig-embedded

Todos los issues de bytecodealliance/sig-embedded

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.