# Open Hardware Architecture

## STORY wasm vs. risc-v
* https://wilkie.how/posts/kernels_without_abstractions_general

we are seeing a world where there are only three major system designs
in use altogether: Windows, iOS, and Linux.

REASON:
* app developers want to write cross platform programs
* => this needs stability per OS/architecture

WAY OUT:
* design a high level system that works cross platform
* => make it work on newer awesome kernels
* => so write thsoe high level systems shimming/anticipating the better kernel
* => thx to meltdown/spectre it's gonna be RISC-V

ROADMAP ASSUMPTION:

WASM:
* JIT abstract resource independent machine

RISC:
* Newest/Best meltdown/spectre free minimal process architecture

Having "WASM", hardware can start competing
=> linux/macOS/windows get's replaced by WASM
Enough convergent iterations on cpu architecture to support wasm
=> until WASM ISA or X ISA with wasm X machine to emulate X on other architectures
==> wins and we can maybe move on.

WASM for now tries to cover all needs by all languages and software
=> without fixing oneself to a hardware, but explicitly not fixing oneself to one

WASM allows to "share code" between libraries
=> have a host system compose wasm blobs
=> wasm is a machine
==> so wasm machines can be paused and receive inputs
=> whether co-located on same hardware system or not

WASI defines interface of wasm blobs to give it access to host sytem features

developer working on a Mac, Windows, or RHEL workstation or laptop
will be able to compile an application for an edge, IoT, cloud,
or automotive platform, and they will do it using Wasm. Today,
that workflow requires cross-compiling or emulation,
which is inconvenient and/or has lower performance.

WASM GOAL:
safe, fast, portable low-level code on the web

https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc
https://www.infoworld.com/article/3674124/the-ever-widening-world-of-wasm.html
Architecture Competition:
old:
* Intel (x86)
new:
* intel
* RISC-V
* Apple M1/M2
* AWS Graviton
* Ampere
* Fujitsu
* ...

Memory Architecture:
-> load/store

* floating point
* SIMD
* seperated code + data in wasm
==> but wasm blobs get orchestrated by JS
* pointer 32/64
* max data with 32/64
* RISC-V no typing !!!!
* control flow => arbitrary
machine model: register
* memory layout "paged"
* memory protecion RWX
* load-linked/store-conditional
* multithreading
* LL:
1. read word from memory
2. stores address in special LL register
3. LL register is cleared if anything happens that may break atomicity
* a context switch occurs
* block containing address in LL register is invalidated
* SC:
* tests whether address in LL matches store address
* store succeeds => store goes to cache/memory
* failes: store is canceled, 0 is returend

* instruction encoding: fixed length 2/4 bytes
* interaction environment
* imported functions
* vs. syscalls

webassembly (cant even access itself)
* simplicity (so JIT compiler doesnt need to detect modification to update machine code)
* linking will be done by HOST and program doesnt need to care about bringing itself up
* security - generating code at runtime is dangerous

RISC-V perf
WebAssembly security

NEUMANN
* input device
- outputdevice
- cpu
- control unit
- arithmetic/logic unit
- memory

HARVARD
- code storage
- data storage
- input/output devices
- control unit
- ALU