It works perfectly fine, but I rarely start it up because I really don’t have much of a use for it most days. It runs my old software wonderfully, but an emulated version of Mac OS 9 on my modern MacBook Pro is just so much more convenient.įor several years now, I have had an old iMac G3 from about 2000 sitting around in one corner of my home office. Several years ago, I bought an old, colorful iMac G3 running Mac OS 9. This old blog post might contain some more information. a shared heap between the native side and WASM), except maybe that you can also pass 64-bit integers around without data loss.īut in no case there needs to be any JSON- or Protobuf-style 'parameter serialization' involved. This 'number pointer' can then be used as array index to read and write data in the WASM heap from the JS side.ĭon't know how it works in WASM engines outside the browser, but I suppose it's similar (e.g. Since WASM currently only has 32-bit pointers, pointers can be passed safely to the Javascript side as JS 'numbers' without loss of information. 'Primitive types' like integers and floats can be passed to the other side directly as function parameters without marshalling.įor memory access I can only describe how it works in the browser environment with Emscripten (for lack of experience with other WASM integrations): The WASM heap is exposed as a Javascript ArrayBuffer object (or more correctly that ArrayBuffer object is the WASM heap, created on the JS side and handed to the WASM side at startup), with per-primitive-type array views (for instance for byte access there's a global "HEAPU8: Uint8Array" object on the JS side). Especially on hardware that's slow by modern standards to begin with. 29% overhead for verifiably safe sandboxing is a good trade-off, but when you don't actually need that sandboxing, I wouldn't call that insignificant. It sounds like this last one is the most relevant to porting code to obscure platforms (which usually means embedded these days). Other sandboxing improvements are possible too - almost no effort has gone into this yet." If we are willing to relax that (but we may not want to call it wasm if we do) then we can use masking sandboxing instead (see section 3.1.3 in Tan, 2017), which is 100% portable like explicit sandboxing and also prevents any accesses outside of the sandbox, and is somewhat faster at 29% overhead. Explicit and OS-based sandboxing preserve wasm semantics perfectly, that is, a trap will happen exactly when a wasm VM would have trapped. There are more options in between those 14% and 42% figures. It has just 14% overhead! However, it cannot be used everywhere (it needs signals and CPU memory protection, and only works on 64-bit systems). That is fully safe and has the benefit of avoiding explicit bounds checks. This technique reserves lots of memory around the valid range and relies on CPU hardware to give us a signal if an access is out of bounds (for more background see section 3.1.4 in Tan, 2017). The OS-based implementation uses the “signal handler trick” that wasm VMs use. The first is explicit sandboxing, in which each memory load and store is explicitly verified to be within the sandboxed memory using an explicit check (that is, an if statement is done before each memory access). "Two results are shown for WasmBoxC, representing two implementations of memory sandboxing. That would be inconvenient but good enough for bootstrapping purposes, so a translation layer still wouldn’t really help.įrom that link, it also sounds like 14% is the best case that requires some help from the underlying OS: But even in that case, it’s possible to separate the compile and link steps, so you could compile an object file on another system, copy the object file to the target system, and run the linker from there. In this case it’s impossible to cross-compile for the target normally (at least without using a nondefault linker such as LLD). This is true on modern macOS and Windows. If it doesn’t, then it doesn’t, and even if you managed to run the compiler on Mac OS 9 (through a translation layer or otherwise), it would still only be able to produce code for its supported targets.Īn exception to this principle is the linker: the Rust compiler relies on an external linker, and it may happen that the standard linker for a system only runs on that system itself. If it does, then you could cross-compile Rust code for Mac OS 9 from any other supported system – including cross-compiling the compiler itself if desired. Either the compiler supports the instruction set and executable format used on Mac OS 9, or it doesn’t. For the Rust compiler, like most modern compilers, the list of systems it can produce binaries for is independent of which system it is running on.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |