rustation

I've followed the discussion regarding how ASM should be integrated in Rust over the past few years, the idea of integrating the ASM syntax more tightly with Rust has been brought up. Basically one could treat assembly as an ad-hoc domain specific language with its own parsing rules that would make it more like a first class citizen instead of a magical character string. I've actually implemented a very simplistic MIPS assembler in a similar way for emulation purposes: https://github.com/simias/rustation/blob/master/src/parallel... I think they were absolutely right not to go down that route, because then you have to basically specify this syntax for every possible architecture targeted by Rust. Integrating ASM in the language syntax is fine if you only care about x86, but it's going to be a mess if you want to support MIPS, ARM32, AARCH6

Writing an emulator is not really embedded programming (the target often qualifies as an embedded environment but the host can be any random desktop computer). It's definitely possible to write an emulator without unsafe code. Here's a toy gameboy emulator I wrote a while ago in Rust without any unsafe code: https://github.com/simias/gb-rs Here's a very incomplete PSX emulator with only a single unsafe (which might not even be necessary anymore, I haven't updated the code in a while): https://github.com/simias/rustation

I've never implemented an assembler but I did implement a few toy disassemblers and emulators and you'd need a bit more than a simple LUT for many architectures. In particular some ISAs have "modular" opcodes so to speak, where a machine opcode contains several fields that can be mixed and matched. For instance the ARM instruction set has a 4 bit condition code in each instruction so "add" "addeq" (add if equal) and "addne" (add if not equal) are basically the same opcode with a different condition flag. Furthermore not all instructions have necessarily the same layout, so your "LUT" must also contain enough information on how to pack the opcode and its operands correctly. Lastly assembly opcodes don't necessarily map one-to-one with machine code, it's not rare that a single assembly directive would result in multiple machine opcodes. For