{"action":"created","issue":{"url":"https://api.github.com/repos/WebAssembly/tool-conventions/issues/49","repository_url":"https://api.github.com/repos/WebAssembly/tool-conventions","labels_url":"https://api.github.com/repos/WebAssembly/tool-conventions/issues/49/labels{/name}","comments_url":"https://api.github.com/repos/WebAssembly/tool-conventions/issues/49/comments","events_url":"https://api.github.com/repos/WebAssembly/tool-conventions/issues/49/events","html_url":"https://github.com/WebAssembly/tool-conventions/issues/49","id":308197157,"number":49,"title":"What do we ideally want the assembly (LLVM .s) text format to look like?","user":{"login":"aardappel","id":4663648,"avatar_url":"https://avatars2.githubusercontent.com/u/4663648?v=4","gravatar_id":"","url":"https://api.github.com/users/aardappel","html_url":"https://github.com/aardappel","followers_url":"https://api.github.com/users/aardappel/followers","following_url":"https://api.github.com/users/aardappel/following{/other_user}","gists_url":"https://api.github.com/users/aardappel/gists{/gist_id}","starred_url":"https://api.github.com/users/aardappel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aardappel/subscriptions","organizations_url":"https://api.github.com/users/aardappel/orgs","repos_url":"https://api.github.com/users/aardappel/repos","events_url":"https://api.github.com/users/aardappel/events{/privacy}","received_events_url":"https://api.github.com/users/aardappel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-03-23T22:31:57Z","updated_at":"2018-05-14T19:16:05Z","closed_at":null,"author_association":"NONE","body":"We just landed a first version of the assembly parser in LLVM https://reviews.llvm.org/D44329. This version is quite basic and adheres closely to what the disassembler had been outputting so far.\r\n\r\nNow that we have both the assembler and dissassembler though, we can decide to make changes to this format that better suit future needs.\r\n\r\nIn particular, we currently have 2 flavors of the `.s` format:\r\n\r\n- Elf (`-triple=wasm32-unknown-unknown-elf`).\r\n\r\n    - This is the format that is currently consumed by `s2wasm`, so any changes to the format would also have to be made there. Since in the long run the toolchain will be all-binary by default, at which point `s2wasm` will maybe not be needed anymore, it may not be wise to invest too much in changing this format.\r\n    - This path currently defaults to using `-disable-wasm-explicit-locals`, i.e. it may have `$0` as an operand to refer to local 0, instead of a preceding `getlocal 0` instruction.\r\n\r\n- Wasm (`-triple=wasm32-unknown-unknown-wasm`).\r\n    - This corresponds to the wasm-specific `.o` format that gets directly consumed by `lld`. This is the path we are working towards the toolchain taking. Once that path is default, the function of the `.s` format is mostly intended for:\r\n        - Inline assembly.\r\n        - Writing LLVM tests.\r\n        - Viewing `.o` file contents.\r\n        - Writing `.o` files by hand? :)\r\n    - This format is intended to be used with explicit locals, as this matches the `.wat` format more closely.\r\n    - This format currently has no-one depending on it (afaik), so we can change this more easily to suit the above needs by just changing the assembler and disassembler together.\r\n    - This triple doesn't currently work since it requires an implementation of a part of LLVM that we only have for ELF (since it is also used by other \"CPUs\"), which we may add next. The parser itself already deals with all variants above.\r\n\r\nThe current disassembler outputs pseudo stack registers to make wasm look more like a CPU/register machine, and maybe make it easier for humans to track the stack, for example:\r\n\r\n    i32.const $push0=, 1\r\n    i32.const $push1=, 2\r\n    i32.add $push2=, $pop0, $pop1\r\n\r\nThis however is also verbose, so for the use of inline assembly in particular, it may be nice to allow people to write pure stack code. Or even better, we can decide that for the wasm mode above, we require that these stack operands not be present.\r\n\r\nThe LLVM table-gen assembly matcher used in the assembler currently requires there to be operands, so even if we ignore or disallow these operands in the `.s` format, they will temporarily be generated on the fly. The current implementation can't do this yet, and instead relies on them to be present (and correctly numbered).\r\n\r\nIn general, I think we want the `.s` format be as close as possible to the `.wat` format, while still fitting the LLVM mold.\r\n\r\nAnything else we should change about the `.s` format while we're at it? Am I missing something?"},"comment":{"url":"https://api.github.com/repos/WebAssembly/tool-conventions/issues/comments/388930972","html_url":"https://github.com/WebAssembly/tool-conventions/issues/49#issuecomment-388930972","issue_url":"https://api.github.com/repos/WebAssembly/tool-conventions/issues/49","id":388930972,"user":{"login":"aardappel","id":4663648,"avatar_url":"https://avatars2.githubusercontent.com/u/4663648?v=4","gravatar_id":"","url":"https://api.github.com/users/aardappel","html_url":"https://github.com/aardappel","followers_url":"https://api.github.com/users/aardappel/followers","following_url":"https://api.github.com/users/aardappel/following{/other_user}","gists_url":"https://api.github.com/users/aardappel/gists{/gist_id}","starred_url":"https://api.github.com/users/aardappel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aardappel/subscriptions","organizations_url":"https://api.github.com/users/aardappel/orgs","repos_url":"https://api.github.com/users/aardappel/repos","events_url":"https://api.github.com/users/aardappel/events{/privacy}","received_events_url":"https://api.github.com/users/aardappel/received_events","type":"User","site_admin":false},"created_at":"2018-05-14T19:16:05Z","updated_at":"2018-05-14T19:16:05Z","author_association":"NONE","body":"Unlike what I wrote above, we didn't actually have a disassembler yet (binary -> MC). What we've always had is the instruction printer (MC -> text). The assembler is also (text -> MC), so both feed into MC in the same way.\r\n\r\nThere is now an initial disassembler: https://reviews.llvm.org/D45848. Also, both `elf` and `wasm` mode for the moment share the same parser extension (for directives, etc): https://reviews.llvm.org/D45386\r\n\r\nThe big question right now comes back to what I wrote above: do we want a pure \"stack\" based version of these tools? This looks to be a bit more complicated than I originally thought, since all these tools communicate over an `MCInst` (and `MCOperand`) which are generic instruction storage, and their precise definition for a particular target is \"whatever is defined in table-gen .td files\". I originally assumed that improving these tools was just a matter of changing our text parsing/output, but it now seems like we'd need stack based instruction definitions in .td. to make this happen. Now, for some instructions (`call` and `call_indirect`) there already exist non-register versions, but I am not sure if these could easily be added for all instructions, or worse, wether this would need a second set of .td files.\r\n\r\nSince the use cases for the .s file format are minimal, I am not sure whether going thru the above is warranted. I'd love some opinion on the above. We could also revisit this later, and declare we're happy with pseudo-registers for the moment?\r\n"}}
{"actor":{"display_login":"aardappel"}}