WASM: Implement WASMAssembler Class #1675
Conversation
Shaikh-Ubaid
force-pushed
the
wasm_assembler
branch
from
cb52e88
to
2bcb992
Compare
Shaikh-Ubaid
changed the title
Shaikh-Ubaid
force-pushed
the
wasm_assembler
branch
from
ab1888d
to
5fcf60f
Compare
|
This is ready. Please review and share feedback. |
|
|
|
This PR might have conflicts with the sync PR. I will rebase (and/or resolve any conflicts) after completion/merging of the sync PR. |
Marking it for draft until then. |
Shaikh-Ubaid
force-pushed
the
wasm_assembler
branch
from
ae269a8
to
0877372
Compare
|
This is ready. Please review and share feedback. |
| Vec<uint8_t> m_global_section; | ||
| Vec<uint8_t> m_export_section; | ||
| Vec<uint8_t> m_code_section; | ||
| Vec<uint8_t> m_data_section; |
There was a problem hiding this comment.
I think this part should go into WASMFormat class. The WASMAssembler should just create the m_code_section part, the rest should be handled by WASMFormat.
There was a problem hiding this comment.
The WASMFormat Class is named as WASMAssembler here. The WASMAssembler which just creates the m_code_section is named as WASMInstsAssembler. I will update the names if these are confusing.
Currently, the WASMAssembler class inherits from WASMInstsAssembler thereby obtaining/having all the features/powers of creating the wasm format as well as the wasm instructions.
There was a problem hiding this comment.
Yes, the names are confusing to me. I would keep them completely separate no inheritance. The "assembler" knows how to convert instructions to a binary representation. The "binary format" knows how to create sections, headers, etc. and how to create the final binary. It just copies over the result from the "assembler". If you want, we can discuss this at our meeting more and see what would be a good design.
There was a problem hiding this comment.
The code section in wasm along with storing instructions, also stores local variables of the function. Also, for every code section defined in m_code_section, there must be a function type (added/referenced from m_type_section) in m_func_section. Thus, it seems wasm instructions are not fully separate from wasm format. Hence, currently, the approach in this PR defines WASMAssembler as a single interface to wasm related operations.
Sure Sir, we can discuss it in the meet. Any approach works for me.
There was a problem hiding this comment.
I updated the above comment #1675 (comment).
There was a problem hiding this comment.
I think this is fine. We have the "intruction assembler" class that is automatically generated and handles just converting instructions to binary, into the code section (only). Then we have the "full assembler" class that is built on top and handles everything else and emits the whole WASM binary format, which contains various sections and other parts that must work well together.
Rename type to var_type Also define and use vt2s() and k2s()
Shaikh-Ubaid
force-pushed
the
wasm_assembler
branch
from
0877372
to
0b95d97
Compare
There are considerable changes in lcompilers/lpython#1675. After its merging, I think it is better to sync the wasm backend early to avoid potential conflicts in future.
There are considerable changes in lcompilers/lpython#1675. After its merging, I think it is better to sync the wasm backend early to avoid potential conflicts in future.
fixes lfortran/lfortran#589
Also towards #1485