The goal is to have a webapp that allows users to edit, run, and trace assembly code.
This project is under active development.

You can access the app at web.assembliss.app

1. clone this repo
2. generate the required certificates inside nginx/certs (see README)
3. install docker
4. cd into the folder for this repo
5. run docker compose up
6. you should be able to access the app at https://localhost

1. clone this repo
2. generate the required certificates inside nginx/certs (see README)
3. install docker
4. install vs code
5. install vs code dev container extension
6. open the repo folder on vs code
7. open the command palette (cmd + shift + p for mac, ctrl + shift + p for windows/linux)
8. run the command Dev Containers: Reopen in Container
   • vs code will build the docker container for you (it might take a minute)
   • vs code will reload the window so you're inside the container
9. open a terminal through vs code
   • this terminal is running inside the container
10. run cd / and python -m webassembliss.app to launch the app
11. you can access it on 127.0.0.1:5000
12. if you make changes to the code through this vs code window, the app will restart and have the changes

• figure out why printf isn't working
• show user output of a specific file they create/modify with their code
  • could allow them to redirect input/output boxes to a filepath
• add a cooldown period after the user runs code a few times (could be 1min after each run or an exponential backoff)
• add support for more architectures
  • overview how to do that: #1
  • 8086
  • x8664_windows
  • mips
  • armv7

• allow c-driver code (this could be resolved as a pre-assembled object file)
  • pre-assembled object files are done... but printf output does not show for some reason.

• add auto-format
  • https://github.com/jpetrucciani/black-check
• add auto-lint
  • https://github.com/rhysd/actionlint
• add auto-typehint-checker
  • https://github.com/python/mypy
• cleanup the language syntax for each architecture
  • maybe helpful? (monarch)
• move these TODOs to the projects tab
• update Dockerfile to use newer python version
• explore a switch from gcc to clang since it supports multiple architectures by default
  • maybe helpful?
• add unit tests for all methods
  • maybe with pytest?
• CI/CD to auto-run tests on open PRs
• swap flask with fastapi
  • maybe helpful?
  • might need to adapt rocher?
• make run and trace routes and methods async
  • maybe helpful? (flask)
  • maybe helpful? (fastapi)
• find best gunicorn config
  • https://docs.gunicorn.org/en/stable/settings.html#worker-class
  • https://docs.gunicorn.org/en/stable/design.html

• allow user to change timeout
• add a button to load code from examples

• add a button to assemble, link, and run the code from the editor
• show output of the code in page
• allow user to provide input to the code
• show registers after execution
• show memory
• highlight modified registers
• show condition codes / status bits
• handle qiling exception (qiling.exception.QlErrorCoreHook: _hook_intr_cb : not handled) when code does not exit or timeout
• allow user to debug code (continue, step, set breakpoint, see memory)
  • solved with tracing
• make sure app works with multiple users accessing concurrently
• make sure debugging works with multiple users accessing concurrently
  • solved with tracing
• created a sandbox for each user emulation
  • fix sandbox vulnerability with absolute paths
• allow multiple sources to work together
  • backend is able to handle it
  • process all sources from frontend
• allow user to provide pre-assembled object file(s) to be linked with editor's sources
• remove as/ld and just use gcc
  • if we assume that clients use the trace method, each arch should be able to choose their build
• remove flask-session
  • store everything client-side with localstorage
  • receive all files in the request json body
  • limit the max request size a user can send
  • change all logic that used tab_manager to use local tabs
  • delete tab_manager route and remove flask_session dependencies
• refactor backend to have a single run/trace route that receives the arch as parameter
• refactor backend to only have trace; if the user wants to run, simply combine all steps
  • refactor the grader route (and any other calls) to use the trace route
• refactor the frontend so the editor is generic and new archs only need to provide the syntax highlighting and help links
• implemented riscv
• implemented x8664_linux
• allow testing of code (given input, expected output)
• measure lines of code
• measure executed instructions
• measure documentation level
• create config file that has provided source(s), object(s), and tests
• allow user to upload config file and run tests with their code
• generate a results file containing user info, test results, efficiency metrics
• script to validate that results were generated with correct project config
• move grader protos to the same folder as the tracing ones
• generate object and binaries in a temp folder inside rootfs
• separated js and css from jinja template
• improve the gui
• combine multiple "external trace steps" into a single one, similar to a function step over
• have a toggle for ascii vs non ascii memory view
• allow user to change memory area shown
• change the editor to hilight syntax for assembly
• allow user to download emulation information
• allow user to download code
• allow user to upload code
• allow user to submit an issue through the webapp
• highlight assembler errors in source code
  • update error display for multiple tabs
• preserve source code between refreshes
• allow user to change registers shown
• add a production deployment server
• allow user to upload other files to be processed (e.g., a csv file to be read)
• show instructions executed after running/tracing code
• show instructions written after running/tracing code
• create a form to generate project configs
• show instruction information when hovering over it
• allow user to change themes