GXemul: TODO


Back to the index.

Some things, in approximate Time order, that I'd like to implement or fix. (Things at the top need to be fixed before those at the bottom.) Some items in this list are perhaps already fixed. This is just a place for me to do brain-storming.

Please note that GXemul 0.5.0 will be a complete rewrite of GXemul, from scratch. This file has nothing to do with the TODO files from previous versions of GXemul.

You may also want to read the preliminary documentation:

Please see GXemul's homepage for more information about GXemul in general.



Legend:

[ ] = not started
[/] = started, but not completed
[X] = completed (but these are usually removed from the TODO list)


gxemul-legacy (0.4.6.x) ----------------------- (Only stable bug fixes go into this branch.) [ ] New OpenBSD 4.x install instructions? [ ] Fixes for PPC instructions? [ ] OF fixes... Try to get FreeBSD/macppc to boot further?
Misc. ----- [/] File loader: Load stuff into emulated RAM (or ROM) components. Note: Usually, ELFs contain _virtual_ addresses, so file loading needs to go through a CPU to be properly address translated! BUT BOTH must be possible! I.e. load into RAM, or load into a CPU. [/] File loader, which uses file sensing magic to load using the correct format. [/] ELF [ ] a.out [ ] raw binaries [/] Meta data: [/] Entry point [ ] symbols [ ] line number information [ ] data type information, etc. [ ] Files loaded at startup should be part of the emulation setup! [ ] save/load should include those files, so that loading apa.gxemul will load the files that were used in that setup! [ ] Add a method on the CPUComponent, "loadfile", so that files can be loaded during runtime, and not only at startup. How about multiple files? And how about "reset"? The list of files must be stored somewhere. [ ] Don't hardcode the CPU path in GXemul.cc? LookupPath("root.machine0.mainbus0.cpu0"); Or perhaps all template machines have to have this structure? [/] testmips [/] Work on MIPS_CPUComponent::Run() and the generic CPUComponent [X] Connect the CPU to an AddressDataBus. [/] virtual to physical translation [ ] Handling of read/write errors? [/] Disassembler: Migrate most/all functionality from GXemul 0.4.6.3. [ ] Start interpreting instructions! [ ] MIPS16: Convert to 32-bit instructions (?) [ ] 32-bit instruction words [ ] Unit tests! [ ] Framebuffer device :-) [ ] Start with SMP early on. [ ] Caches! [ ] Native code generation... etc. [/] State variables: [ ] Write more unit tests! [ ] Special handlers for Read, Write, Serialize, Deserialize. [/] RAM component: [X] Implement a generic AddressDataBus interface. [ ] STATE! serialize/deserialize, including unit tests [/] Mainbus component: [X] Forward accesses to individual other devices/components. [ ] Handle overlaps in MakeSureMemoryMapExists some nice way. [ ] AddressDataBus should be extended to allow for direct page mapping. [ ] Unit tests for the above! [ ] Main run loop: Verify that both cycle accurate and larger chunks works well. Unit test? [ ] Components [ ] "help" about components could show a file:/// link to the installed documentation about that component or machine! (If it exists.) [ ] Reintroduce the -e command line option, for "model hint" given to the machine template. (3max, for the decstation type) Not only for templates. E.g. a MIPS processor, with' subtype "R3000" instead of "5Kc" or so... Perhaps -C too then? [ ] How about aliases? 5000/200, 3max etc. vs pmax/DECstation? Aliases + comments, for templates. [ ] Limit where components can be added. Like "drop targets"? E.g. a machine can be added at the root, but a machine can not be added on a pcibus. Similarly, a pcibus can not be added at the root. It has to be in a machine of some kind. Think about this. Perhaps as simple as a "if parent class is not blah blah then disallow adding". A machine can be added into a dummy component. A dummy component can be added into a dummy component. A pcibus can be added into a mainbus (in a machine.) etc. bool IsItOkToAddItToThisProposedParentComponent(propsedParent) const; [/] IR: this could be done separately from actual emulation code, and unit tested. src/ir/ [X] IRBlockCache, hold a bunch of natively translated chunks of code. [ ] runtime option to turn off native code generation backends. [ ] IR opcode etc. [ ] Debug dump must be possible. [ ] Load of various types [ ] Store of various types [ ] Arithmetic [ ] Bit logic [ ] Architecture dependent operations (setting/reading status registers, manipulating the TLBs, triggering software interrupts, etc) [ ] Conditional branches [ ] Unconditional branches [ ] Calls to subroutines. Special case for known leaf functions? [ ] Labels. (?) Abstraction framework: [ ] "Run this code" NOTE: If no native target is in use, this should run the code in plain C++! It is ok for this to be not 100% tightly optimized. [ ] Count nr of times a block has been executed; this can be used to go from 1. IR only, to 2. native, but not optimized 3. native, heavily optimized etc. [ ] Internal helpers such as "mark this as executable in memory". [ ] Initial target: amd64. [ ] Should generate machine code directly in memory, should not depend on any specific assembler's syntax. [ ] Optimizations? [ ] Target-independent? [ ] Per target. [/] Unit tests. (These probably only run if the host matches one of the supported targets.) E.g. for each IR instruction, and/or for each specific optimization. Actions and undo/redo --------------------- [ ] Undo/redo commands should show what they are doing, e.g. Undoing "add component" or Redoing "remove component". Preferably even including arguments. :-) Think about this. [ ] CompoundAction Contains multiple actions in a row. If ALL actions inside are undoable, then the action is undoable, and executing Undo should undo them all (in reverse order). Constructor should probably take a vector of other Actions (?). [/] VariableAssignmentAction [X] Undoable by remembering old value of a state variable. [ ] Assignment of Component names! Currently bugs out! cpu0.name = "monkey" must be undone by monkey.name = "cpu0" [ ] Handler for 'name' should verify the name. [ ] Handlers for specific registers, e.g. bits fixed to 0 or 1 in registers... [ ] Assignment of arrays? Or elements in arrays... [ ] Call trigger's callback (?). [ ] MoveComponentAction Undoable by remembering position, similar to Remove, where the component was before. Triggers -------- [X] GXemul should hold one Triggers instance. [ ] ActionStack unit tests: test that correct triggers are triggered :) [ ] Renaming components should update names of all triggers! Move all triggers to a new temporary map? Then swap. [ ] When removing (parts of) the component tree, triggers should be removed as well. When undoing the remove, triggers should be added again (?). [ ] Command available only in DEBUG builds: Dump all triggers' names? (During development.) [ ] "Aggregate" multiple changes by holding back the actual call to callback functions, until the aggregate lock is released. Changed |= changed for each, etc... [ ] Triggers on Component StateVariables, i.e. writes to state variables should trigger triggers. [ ] Non-document triggers, i.e.: [ ] UI::UpdateUI should be refactored away: [ ] Undo/Redo applicability changes [ ] RunState changes [ ] The name of the emulation changes CommandInterpreter ------------------ [ ] Some commands only available in DEBUG builds? E.g. for dumping internal state during development. [/] State variable assignments: [X] Action, to allow Undo. [ ] Expression evaluator, +-*/, string concatenation, etc. [ ] Execution of _expressions_, not just variables. e.g.: cpu.pc prints the pc value cpu.pc+4 should print the _expression_ pc+4 cpu.pc=expr assignment [ ] Help on Method arguments? E.g. cpu.unassemble [addr] [/] Tab completion for everything: [ ] syntax based completion? e.g.: help [cmd] tab completes the first argument as a command add component-name load [filename [component-path]] This will require a uniform way of describing arguments, and whether or not they should be optional. The tab completer must then parse the command line, including figuring out which arguments were optional, etc. Also, when such syntax is taken into account, the CommandInterpreter can check syntax _before_ running Command::Execute. That means that individual Commands do not have to do manual checking on entry that the number of arguments is correct etc. [ ] filename [ ] command name [ ] component path [ ] optional vs mandatory args...? [ ] scan all commands' args at startup, and have an assert() in place, so that unknown arg types are caught during development! [ ] move Move a component from one path to another. [ ] copy copy a component (and its children) to the clipboard [ ] paste paste a component from the clipboard [ ] step single-step (Paused) Components ---------- Start implementing suitable components (src/components/): busses/ mainbus, TurboChannel, ISA, PCI, ... Busses usually just forward read/write accesses to other components. cpus/ [/] mips graphics/ e.g. VGA graphics cards! displays/ rgbmonitor RGB monitor, for e.g. VGA output. lcd LCD display led A single led :) dummy/ dummy components (for unit testing) machines/ Machines are usually TEMPLATES which set up a couple of other components! [/] testmips memory/ Memory keep data in some form of array. [/] ram rom Non-writable during execution? TODO cache(s) network/ Ethernet and others end up here sound/ sound cards I18N ---- [ ] Unit tests to make sure that unicode strings work as expected. [/] Use _(x) everywhere for user-readable strings. [X] Investigate intltool or gettext or whatever is necessary to get it all working. po directories/files, etc. [ ] Compose-style "somethign %s something". [/] Initial translation would be Swedish. LANG=sv_SE.UTF-8 ./gxemul-gui [ ] Use LANG=he_IL.UTF-8 ./gxemul-gui to try a right-to-left languages, or LANG=ja_JP.UTF-8 ./gxemul-gui to try an asian language. Error handling -------------- [ ] Stack of errors? With human readable (i18n'd) messages. (e.g. Exception with possibility to add sub-exception-messages...) GTKMM GUI --------- [ ] Glib::Thread, think about which main threads there should be in the emulator, when running with the GUI (GTKMM). If GTKMM is not used, Glib::Thread should NOT be assumed to be available! [ ] The input line should be focused by default, when starting the application, so that commands may be entered immediately. [ ] Scaling/position of the input line vs text window [ ] Accept INDIVIDUAL keypresses in the input line :) to support e.g. tab completion. [ ] Quit: [ ] Closing the main window using the _close button_ should work the same was as Quit. [ ] Quitting by executing the command "quit" in the text input line should work the same as Quit, i.e. dirty flag question etc. [/] Menu bar: File [/] New -> [X] Blank emulation [/] From template (e.g. "testmips") ----------------------- [ ] GXemul instance [/] Open [ ] (Open can show a list of "thumbnails" of the workspace plus e.g. one main window (such as a VGA display).) [ ] Close ----------- [X] Save [X] Save as... ----------- [ ] list of recently used files ----------- [X] Quit Edit [/] Undo [/] Redo ----------- [/] Cut [/] Copy [/] Paste [/] Delete ----------- [/] Preferences (?) View [ ] Show toolbar [ ] Show workspace [ ] Show debug console [ ] Full screen mode (F11, CTRL-ALT-F11 to get out) Emulation [/] Play/Go It would be nicer if Go/Pause were radio button style, not checkbox style... [/] Pause [X] Reset Help [ ] Contents (installed html files) [X] About [/] Toolbar button area: [ ] Step backwards [ ] Step forward [ ] Run backwards... [X] Run (start emulation) [X] Pause (pause emulation, button kept down until unpaused) [ ] Reset [X] Undo/Redo! (Optional plug-in-ability/extensibility. Buttons should be bound to debugger commands.) [/] "Workspace", where emulations can be created by drag-n-drop of components from a palette, and/or from other emulations. Normally, the workspace window would be docked in the "center" of the GXemul window, with the palette to the right, and the command window below it. [/] Main workspace: [ ] Draw meaningful graphics. [ ] Draw text labels for Components. [ ] Implement drag-and-drop. [ ] Scrollbars if the whole design area isn't possible to fit in the designated rectangle? [ ] Tooltips for components? (A "summary" of the entire state window.) [ ] Palette window, of all available components. [ ] Show components. [ ] Keep size when main window is resized! [ ] Implement drag-and-drop. [ ] Copy/Paste of components! Both inside one GXemul instance, and _BETWEEN APPLICATIONS_! [ ] Make the misc/gxemul-gui.png icon more meaningful! [ ] Dockable/undockable windows for machines/devices/ I/O-units' contents ? Think about ----------- [ ] Inspection of state of any Component... [ ] Monitoring of _state transitions_? [ ] Callstack window, etc. (per CPU). [ ] Memory view with machine code disassembler + show source code lines (if available), including current execution point. [ ] Function call trace window (also per CPU). [ ] Ability to "fold" a branch of the tree! Could be useful. [ ] Ability to "fold" _all_ branches that have a specific symbol. E.g. fold all "printf" calls, so that individual putchars are never displayed if they are called from the printf tree, but they will be displayed if they are called from elsewhere. [ ] Profiling using profil()? On host archs that support it. That way, the _generated_ runtime code could be profiled from within the emulator. [ ] ARBITRARY break conditions, i.e. between each instruction, check any number of arbitrary conditions: x) Contents of memory locations, even including stuff on the stack x) Reads/writes from memory? x) Any flags or other device state (registers). This obviously slows things down A LOT, so the default is to have no such break conditions. [ ] Optionally increase counters instead of breaking, for statistics gathering. (Of course, it should then be possible to set a break condition such as expr > 50 or so) [ ] Compile these conditions into some form of internal byte code? [ ] Cache emulation, multiple hierarchies, etc. [ ] Timing modes: 1) Real-time approximation. (For guest OSes.) 2) Fixed. (For fixed 1 instruction/cycle speed.) Each device must then have a specified speed (such as 50 MHz...) It should be possible to switch timing modes during an emulation, but going back after such a switch does not have to be possible. [ ] Generic timer framework [ ] Generic interrupt framework [ ] Generic network emulation framework [ ] Support SLIP/PLIP in emulated guest OS? [ ] Connect to real world via: [ ] Built-in NAT layer [ ] Perhaps VDE or similar? [ ] PROM emulation in software: Some kind of plugin system, allowing machines to plug in software PROM emulation packages. [ ] Regular saving of state with time stamps (i.e. cycle numbers), so that running "backwards" is possible! NOTE: 1) This must include network packages and disk image contents! Tricky. But perhaps doable. 2) Must be possible to use both from the UI (a "step backwards" button?) and the debugger. A kind of "exponential decay"-kind of discarding of old states is probably the best way to do it. Typical use case: something bad has happened (a NULL crash or similar in a kernel), and you ask "Who was the last one to write to this variable?". Running backwards/replaying the emulation will then be able to find the instruction which write the NULL value. [ ] "Live migration" might be possible. Or at least migrating while the emulation is being paused. (Not very live-ish, but perhaps this can be tweaked.) [ ] Actual machines being emulated 1 per process/thread? Or all in the same process/thread? [ ] Try to take advantage of SMP hosts. [ ] The GUI needs the be threaded anyway, for responsiveness. [ ] Prepare early on for emulation using multiple hosts (or GXemul instances) [ ] Full-screen. CTRL-ALT-F11 toggles full-screen vs docked window in the designer view? CTRL-ALT-F12 toggles mouse capture? [ ] There can now be links directly into the documentation, assuming it is installed. ($PREFIX/share/doc/gxemul/*.html) I.e. F1 (and Help->Contents) can cause a web browser to be launched. F1 in dialogs could link to a page with screenshots + description of each dialog. [ ] Userland emulation! Both from the command line, and from the GUI? (Startable, at least.) Possibility to inspect cache misses, etc. -u emulname should imply -q. [ ] Command-line options compatible with pre-0.5.0! Start e.g. framebuffers in full-screen / windowed mode, _not_ docked. [ ] Hot-swap of devices during runtime, depends on Bus support. e.g.: Floppies CDROMS Some harddisks? PCMCIA USB Serial devices Parallel devices VGA monitors ADB Sun's old bus for keyboards/mice ... [ ] TFTP server built-in into the simulated gateway? For netbooting. [ ] GDB debug connection (again). Building on other platforms --------------------------- [ ] Cygwin. Known issues preventing build on CYGWIN: [ ] The configure script cannot run grep using variables (?) which causes header files to be generated in a corrupt manner. [ ] -Werror doesn't work well with STL; STL gives warnings about uninitialized stuff. This was on the following system configuration: uname: CYGWIN_NT-5.2-WOW64 sh version: GNU bash 3.2.33(18)-release (i686-pc-cygwin) C++ version: GNU C++ 3.4.4 Preparation for release 0.5.0 ----------------------------- x) Not meaningful until enough functionality from the 0.4.x series have been duplicated. AT LEAST the following before the release: o) testmips! o) working GUI with at least some basic functionality o) at least one REAL mips machine, such as pmax! o) basic debugger commands: trace tree, single step, registers, etc. o) some form of native code generation x) Carefully read through all the source code. x) Build on as many platforms as possible, including running unit tests. x) Documentation: x) Mention in the documentation the recommended way to do customized distributions of gxemul (by naming the directory gxemul-MyVer-1.2.3 etc, and supplying all source code). + SECONDARY_MSG in misc.h. x) Automated build of list of CommandInterpreter Commands + long description as HTML? x) User guide with screenshots of the new GUI, _BUT_ the instructions should always mention how things are done using the text-only UI as well. x) guestoses.html page in the same location as the legacy version, but with links into various Machine pages (where the actual documentation for guest OSes are). x) When making a release: Make sure to run "make documentation" in the release-named directory, so that html documentation about components and machines is produced for the Stable version, and not the Development version! x) Carefully check that the man page reflects the correct command line options etc. x) Carefully read through all the documentation, and test all instructions given there. x) Check the Swedish translation. x) Take reasonable screenshots of the new version, and place on the homepage. In particular, take a small thumbnail screenshot, and place above the text "Introduction" in the lefthand navigation section, on all pages. (And replace the icon on gavare.se for GXemul with this icon, and perhaps also on Wikipedia?) x) Screenshots of simple bootup of guest OSes (maybe even amd64 guest OSes?) x) Screenshots of the GUI, when debugging. x) Screenshots of running in text console mode, e.g. booting a netbsd kernel, and then single-stepping. x) Make sure that the web page looks reasonable. There should be clear ways to download the old 0.4.x version in addition to the 0.5.0 release, even when 0.5.0 has been released. After releae 0.5.0 ------------------ x) More archs: Add the old ones again: [ ] ARM [ ] PowerPC/POWER [ ] SuperH Add the old non-finished or legacy ones: [ ] Alpha [ ] Motorola M88K [ ] AVR [ ] amd64 Continue on other skeletons: [ ] SPARC General notes for ANY 0.5.x release ----------------------------------- x) Mention the RELEASE in the HISTORY file. x) Create .tar.gz release package: x) remove all .svn directories x) run ./configure; make documentation; make clean_all x) Verify that the package builds as expected on one or more machines. x) Branch (for 0.5.x) and/or tag (for 0.5.x[.y]) in SVN. x) Home page updates: x) index.html: x) Version numbers x) news.html: x) Version number, News entry x) download.html: x) Version numbers x) Link to .tar.gz x) SourceForge link x) RELEASE note excerpt x) After rsync:ing, make sure to remove old LATEST_IS_x.x.x.x files! x) Once the home page has been updated: x) Verify that the .tar.gz is downloadable, and works. x) Upload .tar.gz to SourceForge's File Release system x) Post message to the gxemul-users mailing list. Note to package maintainers that it is highly recommended to assume that old descriptions and makefiles etc are not valid anymore. Give example description? x) Update FreshMeat Both the 0.4.x branch and the 0.5.x branch. x) Update WikiPedia The Usage Example and Dynamic Translation sections should probably be removed, and the screenshot replaced. Also, comment about the new vs the old version (archs, guest OSes).