Top Qs
Linha do tempo
Chat
Contexto

WebAssembly

Da Wikipédia, a enciclopédia livre

Remove ads

WebAssembly (às vezes abreviado como Wasm) é um padrão aberto que define um formato de código binário portátil para programas executáveis e uma linguagem assembly textual correspondente, bem como interfaces para facilitar as interações entre esses programas e seu ambiente hospedeiro.[2][3][4][5] O principal objetivo do WebAssembly é habilitar aplicativos de alto desempenho em páginas web, mas o formato é projetado para ser executado e integrado em outros ambientes também, incluindo os autônomos.[6][7][8]

Factos rápidos Paradigma, Surgido em ...

WebAssembly (ou seja, WebAssembly Core Specification (então a versão 1.0, 1.1 está em rascunho[9]) e WebAssembly JavaScript Interface[10]) tornou-se uma recomendação do World Wide Web Consortium em 5 de dezembro de 2019,[11] junto com HTML, CSS e JavaScript.[12]

WebAssembly pode suportar (pelo menos em teoria) qualquer linguagem (por exemplo, compilada ou interpretada) em qualquer sistema operacional (com a ajuda de ferramentas apropriadas),[13] e na prática todas as linguagens mais populares já têm pelo menos algum nível de suporte.

O Emscripten SDK pode compilar qualquer código-fonte escrito em linguagens suportadas por LLVM (como C, C++ ou Rust, entre outras) em um arquivo binário que é executado na mesma sandbox como código JavaScript.[nota 1] Emscripten fornece ligações para várias interfaces de ambiente comumente usadas, como WebGL. Não há acesso direto ao Document Object Model (DOM); entretanto, é possível criar funções proxy para isso, por exemplo através de stdweb,[18] web_sys,[19] e js_sys[20] ao usar a linguagem Rust.

As implementações do WebAssembly geralmente usam compilação ahead-of-time (AOT) ou just-in-time (JIT), mas também podem usar um interpretador. Embora as implementações atualmente mais conhecidas possam ser em navegadores web, também existem implementações sem navegador para uso geral, incluindo WebAssembly Micro Runtime,[21] um projeto da Bytecode Alliance (com o subprojeto iwasm code VM suportando "interpretador, compilação ahead-of-time (AoT) e compilação Just-in-Time (JIT)"[22]), Wasmtime,[23] e Wasmer.[13]

O World Wide Web Consortium (W3C) mantém o padrão com contribuições da Mozilla, Microsoft, Google, Apple, Fastly, Intel, e Red Hat.[24][21]

Remove ads

História

O WebAssembly foi anunciado pela primeira vez em 2015,[25] e a primeira demonstração foi a execução do Angry Bots do Unity no Firefox,[26] Google Chrome,[27] e Microsoft Edge.[28] As tecnologias precursoras foram asm.js da Mozilla e Google Native Client,[29][30] e a implementação inicial foi baseada no conjunto de recursos do asm.js.[31] A tecnologia asm.js já fornece velocidades de execução de código quase nativas[32] e pode ser considerada uma alternativa viável para navegadores que não oferecem suporte ao WebAssembly ou que o desativaram por motivos de segurança.

Em março de 2017, o projeto do produto viável mínimo (MVP) foi declarado concluído e a fase de prévia encerrada.[33] No final de setembro de 2017, o Safari 11 foi lançado com suporte. Em fevereiro de 2018, o Grupo de Trabalho WebAssembly publicou três rascunhos de trabalho público para a Especificação Central, Interface JavaScript, e API Web.[34][35][36][37]

Remove ads

Implementações

Embora o WebAssembly tenha sido projetado inicialmente para permitir uma velocidade de execução de código quase nativa no navegador da web, ele foi considerado valioso fora disso, em contextos mais generalizados.[38][39] Uma vez que os ambientes de tempo de execução (RE) do WebAssembly são máquinas de pilha virtual de baixo nível (semelhantes a JVM ou Flash VM) que podem ser incorporadas em aplicativos hospedeiros, alguns deles se tornaram ambientes de tempo de execução autônomos como Wasmtime e Wasmer.[8][13]

Em novembro de 2017, a Mozilla declarou o suporte "em todos os principais navegadores",[40] depois que WebAssembly foi habilitado por padrão no Edge 16.[41] O suporte inclui navegadores móveis para iOS e Android. Em março de 2021, 93% dos navegadores instalados (93% dos navegadores de desktop e 94% dos navegadores móveis) suportam WebAssembly.[42] Mas para navegadores mais antigos, Wasm pode ser compilado em asm.js por um polyfill JavaScript.[43]

Remove ads

Compiladores

Resumir
Perspectiva

Como os executáveis do WebAssembly são pré-compilados, é possível usar uma variedade de linguagens de programação para criá-los.[44] Isso é conseguido através da compilação direta no Wasm, ou através da implementação das máquinas virtuais correspondentes no Wasm. Há cerca de 40 linguagens de programação conhecidas que suportam Wasm como um alvo de compilação.[45]

Emscripten compila C e C++ para Wasm[33] usando Binaryen e LLVM como backend.[46]

A partir da versão 8, um Clang autônomo pode compilar C e C++ para Wasm.[47]

Seu objetivo inicial é oferecer suporte à compilação de C e C++,[48] embora o suporte para outras linguagens de fonte como Rust, linguagens .NET[49][50][45] e AssemblyScript[51] (similar a TypeScript) também esteja surgindo. Após o lançamento do MVP, existem planos para suportar multithreading e coleta de lixo[52][53], o que tornaria o WebAssembly um alvo de compilação para linguagens de programação coletadas como C# (suportado via Blazor), F# (suportado via Bolero[54] com ajuda de Blazor), Python e até JavaScript onde a velocidade de compilação just-in-time do navegador é considerada muito lenta. Várias outras linguagens têm algum suporte, incluindo Python,[55] Java,[56] Julia,[57][58][59] Zig,[60] e Ruby,[61] bem como Go.[62]

Limitações

  1. Em geral, WebAssembly não permite interação direta com o DOM. Toda interação deve fluir por meio da interoperabilidade JavaScript.
  2. Multithreading (embora haja planos para resolver isso).
  3. Coleta de lixo (embora haja planos para resolver isso).
  4. Considerações de segurança (discutidas abaixo)

O WebAssembly é compatível com desktops e dispositivos móveis, mas no último, na prática (para alocações de memória não pequenas, como com o motor de jogo Unity) existem "limitações graves que tornam muitos aplicativos inviáveis para serem implantados de forma confiável em navegadores móveis [..] Atualmente, alocar mais de ~300 MB de memória não é confiável no Chrome no Android sem recorrer a soluções alternativas específicas do Chrome, nem no Safari no iOS."[63]

Todos os navegadores web principais permitem o WebAssembly se Content-Security-Policy não for especificado, ou se "unsafe-eval" é usado, mas, caso contrário, os principais navegadores web se comportam de maneira diferente.[64] Na prática, o WebAssembly não pode ser usado no Chrome sem "unsafe-eval",[65][66] enquanto uma solução alternativa baseada em worker thread está disponível.[66]

Remove ads

Considerações de segurança

Resumir
Perspectiva

Em junho de 2018, um pesquisador de segurança apresentou a possibilidade de usar o WebAssembly para contornar as mitigações do navegador para as vulnerabilidades de segurança Spectre e Meltdown assim que o suporte para threads com memória compartilhada for adicionado. Devido a essa preocupação, os desenvolvedores do WebAssembly suspenderam o desenvolvimento do recurso.[67][68][69] No entanto, a fim de explorar essas futuras extensões de linguagem, o Google Chrome adicionou suporte experimental para a proposta de thread WebAssembly em outubro de 2018.[70]

O WebAssembly foi criticado por permitir maior facilidade de ocultar as evidências para criadores de malware, golpistas e atacantes de phishing; O WebAssembly só está presente na máquina do usuário em sua forma compilada, o que "torna a detecção [do malware] difícil".[71] A velocidade e capacidade de ocultação do WebAssembly levaram ao seu uso na criptomineração oculta no dispositivo do visitante do site.[71][72][67] Coinhive, um serviço extinto que facilita a mineração de criptomoedas nos navegadores dos visitantes do site, afirma que seu "minerador usa WebAssembly e executa com cerca de 65% do desempenho de um minerador nativo."[67] Um estudo feito em junho de 2019 pela Universidade de Tecnologia de Braunschweig (Technische Universität Braunschweig) analisou o uso do WebAssembly nos 1 milhão de websites mais acessados do mundo na lista da Alexa e descobriu que o uso predominante era para criptomineração maliciosa e que o malware era responsável por mais da metade dos sites que usam o WebAssembly estudados.[73][74] Um estudo feito em abril de 2021 pela Universidade de Estugarda (Universität Stuttgart) descobriu que, desde então, a criptomineração foi marginalizada, caindo para menos de 1% de todos os módulos WebAssembly coletados de uma ampla gama de fontes, incluindo também os 1 milhão de websites mais acessados do mundo na lista da Alexa.[75]

A capacidade de ofuscar com eficácia grandes quantidades de código também pode ser usada para desativar o bloqueio de anúncios e ferramentas de privacidade que impedem o rastreamento da web, como o Privacy Badger.

Como o WebAssembly só oferece suporte a fluxo de controle estruturado, é adequado para técnicas de verificação de segurança, incluindo execução simbólica. Os esforços atuais nessa direção incluem o mecanismo de execução simbólica Manticore.[76]

Remove ads

WASI

WebAssembly System Interface (WASI) é uma interface simples (ABI e API) projetada pela Mozilla para ser portável para qualquer plataforma.[77] Ele fornece recursos tipo POSIX, como E/S de arquivo restrito pela segurança baseada em capacidade.[78][79] Existem também algumas outras ABI/APIs propostas.[80][81]

WASI é influenciado por CloudABI e Capsicum.

Solomon Hykes, um cofundador do Docker, escreveu em 2019: "Se WASM+WASI existisse em 2008, não precisaríamos criar o Docker. Isso é o quão importante é. WebAssembly no servidor é o futuro da computação."[82] O Wasmer, lançado na versão 1.0, fornece "contêinerização de software, criamos binários universais que funcionam em qualquer lugar sem modificação, incluindo sistemas operacionais como Linux, macOS, Windows e navegadores web. O Wasm automaticamente coloca os aplicativos em sandbox por padrão para execução segura".[82]

Remove ads

Especificação

Resumir
Perspectiva

Ambiente hospedeiro

O padrão geral fornece especificações básicas para a API JavaScript e detalhes sobre incorporação.[4]

Máquina virtual

O código Wasm (código binário, ou seja, bytecode) deve ser executado em uma máquina virtual de pilha (VM) portátil.[83] A VM foi projetada para ser mais rápida de analisar e executar do que o JavaScript e ter uma representação de código compacta.[48] Uma funcionalidade externa (como chamadas de sistema) que pode ser esperada pelo código binário Wasm não é estipulada pelo padrão. Em vez disso, fornece uma maneira de fornecer interface via módulos pelo ambiente hospedeiro em que a implementação da VM é executada.[84][8]

Programa Wasm

Um programa Wasm é projetado para ser um módulo separado contendo coleções de vários valores definidos pelo Wasm e definições de tipo de programa. Eles são expressos em formato binário ou textual (veja abaixo), ambos com uma estrutura comum.[85]

Conjunto de instruções

O padrão central para o formato binário de um programa Wasm define uma arquitetura do conjunto de instruções (ISA) que consiste em codificações binárias específicas de tipos de operações que são executadas pela VM (sem especificar como exatamente elas devem ser executadas).[86] A lista de instruções inclui instruções de carregamento/armazenamento de memória padrão, numéricas, paramétricas, controle de fluxo e instruções de variáveis específicas do Wasm.[87]

O número de opcodes usados no padrão original (MVP) era um pouco menos do que 200 dos 256 opcodes possíveis. As versões subsequentes do WebAssembly aumentaram o número de opcodes um pouco acima de 200. A proposta WebAssembly SIMD (para processamento paralelo) apresenta um prefixo de opcode alternativo (0xfd) para SIMD de 128 bits. A concatenação do prefixo SIMD, mais um opcode válido após o prefixo SIMD, forma um opcode SIMD. Os opcodes SIMD trazem 236 instruções adicionais para a capacidade SIMD do "produto viável mínimo" (MVP) (para um total de cerca de 436 instruções).[88][89] Essas instruções, os "opcodes finalizados"[90] são implementados no V8 do Google (no Google Chrome) e no mecanismo correspondente no Mozilla Firefox (mas não ativados em versões estáveis dos navegadores web),[91] e também há proposta adicional de instruções para "pós SIMD MVP" posterior, e também há uma proposta "relaxed-simd" separada em discussão.[92]

Esses opcodes SIMD também são portáveis e traduzem para conjuntos de instruções nativos como x64 e ARM. Em contraste, nem JVM do Java (nem CIL) suportam SIMD, no nível de opcode delas (enquanto ambos fornecem paralelo prático algum aumento de velocidade de SIMD), ou seja, no padrão, mas há uma extensão disponível adicionando intrínsecos para SIMD x64,[93] que não seria portável, ou seja, não utilizável em ARM ou smartphones. Os smartphones podem oferecer suporte a SIMD chamando o código assembly com SIMD, e C# tem suporte semelhante.

Representação de código

Em março de 2017, o WebAssembly Community Group chegou a um consenso sobre o formato binário inicial (MVP), API JavaScript e interpretador de referência.[94] Ele define um formato binário do WebAssembly (.wasm), que não é projetado para ser usado por humanos, bem como um formato de texto WebAssembly legível (.wat) que se assemelha a um cruzamento entre expressões S e linguagens de montagem tradicionais.

A tabela abaixo mostra um exemplo de uma função fatorial escrita em C e seu código WebAssembly correspondente após a compilação, mostrado em formato de texto .wat (uma representação textual legível de WebAssembly) e em formato binário .wasm (o bytecode bruto, expresso abaixo em hexadecimal), que é executado por um navegador web ou ambiente de tempo de execução que suporta WebAssembly.

Mais informação Código fonte em C, Formato de texto WebAssembly .wat ...

Todas as constantes inteiras são codificadas usando uma codificação LEB128 de tamanho variável e eficiente em espaço.[95]

O formato de texto WebAssembly é escrito mais canonicamente em um formato dobrado usando expressões S. Para instruções e expressões, este formato é puramente açúcar sintático e não tem diferenças comportamentais com o formato linear.[96] Por meio do wasm2wat, o código acima se decompila para:

(module
  (type $t0 (func (param i64) (result i64)))
  (func $f0 (type $t0) (param $p0 i64) (result i64)
    (if $I0 (result i64) ; $I0 is an unused label name
      (i64.eqz
        (local.get $p0)) ; the name $p0 is the same as 0 here
      (then
        (i64.const 1))
      (else
        (i64.mul
          (local.get $p0)
          (call $f0      ; the name $f0 is the same as 0 here
            (i64.sub
              (local.get $p0)
              (i64.const 1))))))))

Observe que um módulo é gerado implicitamente pelo compilador. A função é, na verdade, referenciada por uma entrada da tabela de tipos no binário, portanto, uma seção de tipos e o tipo emitido pelo descompilador.[97] O compilador e o descompilador podem ser acessados online.[98]

Remove ads

Bibliografia

Remove ads

Notas

  1. De acordo com a documentação oficial, o Emscripten SDK pode ser usado para criar arquivos .wasm que depois podem ser executados em um navegador web.[14][15][16] Mesmo que o Emscripten possa consumir várias linguagens ao usar o Clang, alguns problemas podem surgir.[17]

    Referências

    1. «WebAssembly/design/Semantics.md». GitHub (em inglês). Consultado em 23 de fevereiro de 2021. WebAssembly code can be considered a structured stack machine; a machine where most computations use a stack of values, but control flow is expressed in structured constructs such as blocks, ifs, and loops. In practice, implementations need not maintain an actual value stack, nor actual data structures for control; they need only behave as if they did so.
    2. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 18 de junho de 2019. WebAssembly is an open standard...
    3. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 18 de junho de 2019. WebAssembly is a ... code format
    4. «Conventions — WebAssembly 1.0». webassembly.github.io. Consultado em 17 de maio de 2019. WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure.
    5. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 18 de junho de 2019. ... this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.
    6. «Introduction — WebAssembly 1.1». webassembly.github.io. Consultado em 19 de fevereiro de 2021. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.
    7. Haas, Andreas; Rossberg, Andreas; Schuff, Derek L.; Titzer, Ben L.; Holman, Michael; Gohman, Dan; Wagner, Luke; Zakai, Alon; Bastien, JF (14 de junho de 2017). «Bringing the Web Up to Speed with WebAssembly». SIGPLAN Notices. 52 (6): 185–200. ISSN 0362-1340. doi:10.1145/3140587.3062363. While the Web is the primary motivation for WebAssembly, nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.
    8. «WebAssembly Specification — WebAssembly 1.1». webassembly.github.io. Consultado em 22 de março de 2021
    9. «WebAssembly JavaScript Interface». www.w3.org. Consultado em 24 de junho de 2020
    10. World Wide Web Consortium. «WebAssembly Core Specification». World Wide Web Consortium (W3). Consultado em 9 de dezembro de 2019
    11. «Wasmer - The Universal WebAssembly Runtime». wasmer.io. Consultado em 19 de fevereiro de 2021. Compile everything to WebAssembly. Run it on any OS or embed it into other languages.
    12. «Developer's Guide - WebAssembly». webassembly.org. Consultado em 10 de junho de 2019
    13. «Compiling a New C/C++ Module to WebAssembly». MDN Web Docs (em inglês). Consultado em 10 de junho de 2019
    14. «Building to WebAssembly — Emscripten 1.38.33 documentation». emscripten.org. Consultado em 10 de junho de 2019
    15. «Emscripting a C library to Wasm | Web». Google Developers (em inglês). Consultado em 10 de junho de 2019
    16. «stdweb - Rust». docs.rs. Consultado em 5 de junho de 2019. The goal of this crate is to provide Rust bindings to the Web APIs and to allow a high degree of interoperability between Rust and JavaScript.
    17. «web_sys - Rust». docs.rs. Consultado em 5 de junho de 2019. Raw API bindings for Web APIs. This is a procedurally generated crate from browser WebIDL which provides a binding to all APIs that browser provide on the web.
    18. «js_sys - Rust». docs.rs. Consultado em 5 de junho de 2019. Bindings to JavaScript's standard, built-in objects, including their methods and properties.
    19. «bytecodealliance/wasm-micro-runtime». Bytecode Alliance. 19 de fevereiro de 2021. Consultado em 19 de fevereiro de 2021
    20. «Wasmtime — a small and efficient runtime for WebAssembly & WASI». wasmtime.dev. Consultado em 18 de dezembro de 2020
    21. «Launch bug». GitHub / WebAssembly / design. 11 de junho de 2015
    22. Wagner, Luke (14 de março de 2016). «A WebAssembly Milestone: Experimental Support in Multiple Browsers». Mozilla Hacks
    23. Thompson, Seth (15 de março de 2016). «Experimental support for WebAssembly in V8». V8 Blog
    24. Zhu, Limin (15 de março de 2016). «Previewing WebAssembly experiments in Microsoft Edge». Microsoft Edge dev blog
    25. Lardinois, Frederic (17 de junho de 2015). «Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web». TechCrunch (em inglês). Consultado em 24 de dezembro de 2017
    26. Avram, Abel (31 de maio de 2017). «Google Is to Remove Support for PNaCl». InfoQ. Consultado em 22 de dezembro de 2017
    27. «WebAssembly: a binary format for the web». ②ality – JavaScript and more. 18 de junho de 2015
    28. «Staring at the Sun: Dalvik vs. ASM.js vs. Native». blog.mozilla.org. Consultado em 7 de dezembro de 2019. Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.
    29. Krill, Paul (6 de março de 2017). «WebAssembly is now ready for browsers to use». InfoWorld (em inglês). Consultado em 23 de dezembro de 2017
    30. «WebAssembly First Public Working Drafts». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
    31. «WebAssembly Core Specification». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
    32. «WebAssembly JavaScript Interface». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
    33. «WebAssembly Web API». W3C. 15 de fevereiro de 2018. Consultado em 20 de abril de 2018
    34. «Non-Web Embeddings». WebAssembly. Consultado em 15 de maio de 2019
    35. «Non-Web Embeddings». GitHub / WebAssembly. Consultado em 15 de maio de 2019
    36. «WebAssembly support now shipping in all major browsers». The Mozilla Blog (em inglês). Consultado em 21 de novembro de 2017
    37. «Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16». Microsoft Edge Dev Blog (em inglês). 31 de outubro de 2017. Consultado em 21 de novembro de 2017
    38. «WebAssembly». Can I use. Consultado em 22 de março de 2020
    39. Bright, Peter (18 de junho de 2015). «The Web is getting its bytecode: WebAssembly». Ars Technica (em inglês). Consultado em 23 de dezembro de 2017
    40. «Awesome WebAssembly Languages». 26 de junho de 2018. Consultado em 12 de fevereiro de 2019. Cópia arquivada em 12 de fevereiro de 2019
    41. «LLVM 8.0.0 Release Notes — LLVM 8 documentation». releases.llvm.org. Consultado em 22 de outubro de 2019
    42. «WebAssembly High-Level Goals». GitHub / WebAssembly / design. 11 de dezembro de 2015
    43. Krill, Paul (29 de novembro de 2017). «Direct WebAssembly compilation comes to Rust language». InfoWorld (em inglês). Consultado em 24 de dezembro de 2017
    44. «Frequently asked questions (FAQ) about Blazor». blazor.net. Consultado em 18 de junho de 2018
    45. «AssemblyScript/assemblyscript». The AssemblyScript Project. 9 de setembro de 2020. Consultado em 9 de setembro de 2020
    46. Krill, Paul (26 de outubro de 2017). «What's next for WebAssembly: GC, threads, debugging». TechWorld. Consultado em 24 de dezembro de 2017
    47. «🛤 Garbage collection · Issue #16 · WebAssembly/proposals». GitHub (em inglês). Consultado em 25 de julho de 2019
    48. «Bolero: F# in WebAssembly». fsbolero.io. Consultado em 25 de julho de 2019
    49. «Pyodide: Bringing the scientific Python stack to the browser – Mozilla Hacks - the Web developer blog». Mozilla Hacks – the Web developer blog (em inglês). Consultado em 9 de setembro de 2020
    50. «Julia in the Browser». nextjournal.com. Consultado em 9 de abril de 2019
    51. Fischer, Keno (22 de julho de 2019). «GitHub - Keno/julia-wasm: Running julia on wasm.». Consultado em 25 de julho de 2019
    52. «MRuby in Your Browser». ruby.dj. Consultado em 25 de julho de 2019
    53. «golang/go». GitHub (em inglês). Consultado em 19 de fevereiro de 2021
    54. «Wasm needs a better memory management story · Issue #1397 · WebAssembly/design». GitHub (em inglês). Consultado em 15 de fevereiro de 2021
    55. «WebAssembly/content-security-policy». GitHub (em inglês). Consultado em 17 de fevereiro de 2021
    56. Neumann, Robert; Toro, Abel (19 de abril de 2018). «In-browser mining: Coinhive and WebAssembly» (em inglês). Forcepoint. Consultado em 8 de junho de 2019
    57. Cimpanu, Catalin (24 de junho de 2018). «Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless» (em inglês). Bleeping Computer. Consultado em 8 de junho de 2019
    58. Sanders, James (25 de junho de 2018). «How opaque WebAssembly code could increase the risk of Spectre attacks online». Tech Republic (em inglês). Consultado em 9 de junho de 2019
    59. R, Bhagyashree (30 de outubro de 2018). «Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications». Packt Pub. Consultado em 9 de junho de 2019
    60. Lonkar, Aishwarya; Chandrayan, Siddhesh (outubro de 2018). «The dark side of WebAssembly». Virus Bulletin. Consultado em 8 de junho de 2019
    61. Segura, Jérôme (29 de novembro de 2017). «Persistent drive-by cryptomining coming to a browser near you». Malwarebytes. Consultado em 8 de junho de 2019
    62. Musch, Marius; Wressnegger, Christian; Johns, Martin; Rieck, Konrad (junho de 2019). «New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild». Detection of Intrusions and Malware, and Vulnerability Assessment (PDF). Col: Lecture Notes in Computer Science. 11543. [S.l.]: Detection of Intrusions and Malware, and Vulnerability Assessment. pp. 23–42. ISBN 978-3-030-22037-2. doi:10.1007/978-3-030-22038-9_2. Consultado em 4 de novembro de 2019. Arquivado do original (PDF) em 21 de outubro de 2019Slides (PDF)
    63. Aaron Hilbig; Daniel Lehmann; Michael Pradel (abril de 2021). «An Empirical Study of Real-World WebAssembly Binaries: Security, Languages, Use Cases.» (PDF)
    64. «Symbolically Executing WebAssembly in Manticore». 31 de janeiro de 2020. Consultado em 10 de fevereiro de 2020
    65. «WebAssembly System Interface Repo». GitHub / WebAssembly. 10 de fevereiro de 2020
    66. «Additional background on Capabilities». GitHub (em inglês). bytecodealliance
    67. «reference-sysroot Repo». GitHub / WebAssembly. 12 de janeiro de 2020
    68. «wasm-c-api Repo». GitHub / WebAssembly. 3 de fevereiro de 2020
    69. «The "Wasmer" WebAssembly Runtime is Generally Available». InfoQ (em inglês). Consultado em 19 de fevereiro de 2021
    70. «Design Rationale». GitHub / WebAssembly / design. 1 de outubro de 2016
    71. «Portability - WebAssembly». webassembly.org. Consultado em 28 de julho de 2020
    72. «Conventions — WebAssembly 1.0». webassembly.github.io. Consultado em 12 de novembro de 2019
    73. «Introduction — WebAssembly 1.0». webassembly.github.io. Consultado em 17 de maio de 2019
    74. «Instructions — WebAssembly 1.0». webassembly.github.io. Consultado em 12 de novembro de 2019
    75. Lively, Thomas (19 de fevereiro de 2021). «Final opcodes by tlively · Pull Request #452 · WebAssembly/simd · GitHub». Bytecode Alliance. Consultado em 12 de maio de 2021 via GitHub
    76. Delendik, Yury (19 de fevereiro de 2021). «File wasm-tools/expr.rs at b5c3d98e40590512a3b12470ef358d5c7b983b15 · bytecodealliance/wasm-tools · GitHub». Bytecode Alliance. Consultado em 12 de maio de 2021 via GitHub
    77. «WebAssembly/simd». GitHub (em inglês). Consultado em 14 de maio de 2021
    78. «WebAssembly/relaxed-simd». WebAssembly. 3 de maio de 2021. Consultado em 14 de maio de 2021
    79. «How we made the JVM 40x faster». astojanov.github.io. Consultado em 17 de fevereiro de 2021. ...support for all 5912 Intel SIMD intrinsics from MMX to AVX-512.
    80. «Roadmap». WebAssembly. Março de 2017
    81. WebAssembly Community Group (janeiro de 2020). «WebAssembly Specification Release 1.0». Consultado em 13 de janeiro de 2020
    82. «Folded instructions». GitHub / WebAssembly / spec
    83. «Modules (Binary)». WebAssembly 1.0
    Remove ads

    Ligações externas

    Loading related searches...

    Wikiwand - on

    Seamless Wikipedia browsing. On steroids.

    Remove ads