Design: Datos iniciales y endiannes

Creado en 3 sept. 2016 · 6Comentarios · Fuente: WebAssembly/design

La especificación no dice nada sobre qué orden de bytes usa i32.load . Los programas del mundo real contienen una sección de datos para proporcionar tablas virtuales, datos estáticos, etc. Estas cosas generalmente requieren diferentes tipos de valores. Sin embargo, WebAssembly está limitado a secuencias de bytes en su sección data . Con bytes no se puede emular int32, ya que no saben nada sobre endiannes.

Sería bueno si WebAssebmly tuviera algo similar a estructuras e inicializadores de estructura similar a LLVM. No solo resuelve el problema con los endiannes de datos estáticos, sino que también brinda la oportunidad de disminuir los datos binarios, ya que los números enteros en la sección de datos probablemente consumirán menos bytes en la representación LEB128, mientras que siempre consumen 4 bytes cuando se codifican en la sección de datos.

Las soluciones alternativas actuales son:

no use la sección de datos, use la función de inicializador grande en su lugar
invente su propio formato, incluya el decodificador en el binario de WebAssembly, ejecútelo desde la función start

Fuente

konsoletyper

Comentario más útil

Existen ventajas significativas de no tener que lidiar con múltiples endianidades en todo el ecosistema, y se cree que la probabilidad de que una arquitectura de CPU que no tenga al menos un soporte eficiente para accesos little-endian se vuelva popular en el futuro previsible es muy baja.

sunfishcode en 5 sept. 2016

👍4

Todos 6 comentarios

WebAssembly es little-endian. Parece que AstSemantics.md no menciona esto; Ahora he presentado https://github.com/WebAssembly/design/pull/787 para corregir esto.

Se menciona aquí y aquí y se prueba aquí .

La idea de tener datos codificados en LEB128 en la sección de datos es interesante. Hay varias formas de hacerlo, ya sea con un nuevo tipo de inicializador de datos o con compresión de capa 1 . La compresión de capa 2 también puede ayudar con grandes segmentos de datos en general.

sunfishcode en 3 sept. 2016

Ya entiendo, gracias. ¿No es un requisito demasiado fuerte? No hay ninguna CPU que conozca que use big-endian, pero si por alguna razón aparece una y se usa ampliamente, WebAssembly se ejecutaría en esta CPU con algunos gastos generales.

konsoletyper en 3 sept. 2016

sunfishcode en 5 sept. 2016

👍4

El sábado 3 de septiembre de 2016 a las 4:07 p.m., Alexey Andreev [email protected]
escribió:

Ya entiendo, gracias. ¿No es un requisito demasiado fuerte? No hay CPU yo
sé que usa big-endian, pero si por alguna razón uno aparece y se convierte
ampliamente utilizado, WebAssembly se ejecutaría en esta CPU con algunos gastos generales.
Las CPU MIPS y SPARC son big-endian, aunque SPARC ha tenido little-endian
cargas / tiendas desde hace bastante tiempo, y MIPS tiene variantes de final pequeño.

Hemos implementado soporte para big-endian en V8 mediante intercambio explícito de endianness
código, pero aún no he medido los gastos generales con cuidado.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/WebAssembly/design/issues/786#issuecomment -244548450,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALnq1EEkfh88rAXYByuL9uNcjbsjVnFbks5qmX8agaJpZM4J0Snh
.

titzer en 5 sept. 2016

Sería bueno si WebAssebmly tuviera algo similar a estructuras e inicializadores de estructura similar a LLVM.

Esto ya es posible en WebAssembly exactamente de la misma manera que se hace en C y C ++: antes de que se llame a main (), la función _start puede llamar a las funciones .init_array. No creo que haya nada que hacer aquí.

De acuerdo con @sunfishcode / @titzer sobre endianness.