Bennett/Requirements: Difference between revisions
< Bennett
Created page with " == Base Requirements == * Multiplatform (Linux/Windows. Mac if possible, but has serious challenges) * Needs to support different different architectures: ARM, RISC-V, [othe..." |
No edit summary |
||
| Line 7: | Line 7: | ||
** Needs to support different memory models, different register configurations, etc | ** Needs to support different memory models, different register configurations, etc | ||
** Needs simulator for target architectures, or to communicate with a lab board | ** Needs simulator for target architectures, or to communicate with a lab board | ||
* Display of CPU registers (will depend on architecture) | * Display of CPU registers (which registers are available will depend on architecture) | ||
* Display of Status Flags (will depend on architecture) | * Display of Status Flags (which flags are available will depend on architecture) | ||
* Memory view, with optional disassembly. View should be configurable to show different | * Memory view, with optional disassembly. | ||
* Multiple memory views | ** View should be configurable to show memory in different ways: single word, multiple words, ascii characters, disassembly (word size and disassembly will depend on architecture) and if an address matches the value in a register, the register name should be highlighted next to that address. | ||
* Breakpoints (stop on memory address) | * Multiple memory views need to be available, and individually configurable. | ||
* Watchpoint (stop on value at address) | * Breakpoints (stop on PC reaching memory address) | ||
* Watchpoint (stop on value at address being changed/set to value) | |||
* CPU controls: step [single, multiple], run, reset - is continue just another form of 'run'? | * CPU controls: step [single, multiple], run, reset - is continue just another form of 'run'? | ||
* Output console | * Output console for | ||
* Needs to be extensible to support different simulated memory-mapped peripherals. Peripherals separate from architecture? | * Needs to be extensible to support different simulated memory-mapped peripherals. Peripherals separate from architecture? | ||
== Extras == | |||
* Compilers/assemblers for target architectures | |||
** [https://modexp.wordpress.com/2018/10/30/arm64-assembly/#gnuasm GNU as (GAS)] (part of the gcc suite) will target almost any architecture, but may not produce useful file types (MU0 support is curiously absent, for example) | |||
** Writing an actual assembler is possible but nontrivial. Are there real reasons not to use GAS (mingw under Windows)? Would they function as stopgaps in the short-term? | |||
Revision as of 12:20, 2 March 2021
Base Requirements
- Multiplatform (Linux/Windows. Mac if possible, but has serious challenges)
- Needs to support different different architectures: ARM, RISC-V, [others]
- Needs to be configurable to 8, 16, 24, 32, or 64 bit architecture
- Needs to support different memory models, different register configurations, etc
- Needs simulator for target architectures, or to communicate with a lab board
- Display of CPU registers (which registers are available will depend on architecture)
- Display of Status Flags (which flags are available will depend on architecture)
- Memory view, with optional disassembly.
- View should be configurable to show memory in different ways: single word, multiple words, ascii characters, disassembly (word size and disassembly will depend on architecture) and if an address matches the value in a register, the register name should be highlighted next to that address.
- Multiple memory views need to be available, and individually configurable.
- Breakpoints (stop on PC reaching memory address)
- Watchpoint (stop on value at address being changed/set to value)
- CPU controls: step [single, multiple], run, reset - is continue just another form of 'run'?
- Output console for
- Needs to be extensible to support different simulated memory-mapped peripherals. Peripherals separate from architecture?
Extras
- Compilers/assemblers for target architectures
- GNU as (GAS) (part of the gcc suite) will target almost any architecture, but may not produce useful file types (MU0 support is curiously absent, for example)
- Writing an actual assembler is possible but nontrivial. Are there real reasons not to use GAS (mingw under Windows)? Would they function as stopgaps in the short-term?