Comments (27)
I think an integrated disassembler/debugger would absolutely be useful!
I haven't thought much about it in the design of r68k, though, and I'm going to focus on getting the cpu part usable first, but I am led to believe that you know a little something about both disassemblers and debuggers so you are welcome to come up with some designs how that might work in/with r68k!
from r68k.
Sounds good :) I will try to think of something.
from r68k.
If we're going to implement a disassembler in rust at some point, it would be a requirement, in my opinion to be able to QC that towards a known good implementation, much like we did the CPU. Can't imagine trying without it, in fact.
from r68k.
Yeah that would be good. Not really exactly sure how to do it though.
from r68k.
Would it be possible to create something like libdissasembler.a based on a working program, set up a memory buffer with some bytes corresponding to some instruction, asking for a disassembly of that buffer and checking that both generate the same output?
from r68k.
Sure. Or actually generate a huge program from the QC tests that we already have here for valid instructions.
from r68k.
I can likely add capstone (slimed down to only use the m68k backend) and add a basic Rust interface for it so it can be called from QC tests. Also Capstone supports several instances which can run in parallel so that can be used to compare with.
from r68k.
Yes, the optable contains useful data for the disassembler! It would be able to find the matching entry for the instruction it was looking at, but there's not enough information how to interpret the "holes" in the mask, such as X and Y, if they represent data or address registers, or something else, and also it doesn't know the addressing mode apart from the hints usually present in the function name. So more information would be needed.
Not having to use semaphores to enforce single threaded access would also be great!
from r68k.
True. I guess it may actually be possible to just try all combos from 1 - 65536. Now there will be a bunch of illegals in there but that would be good to validate that it all works anyway (might be bugs on both)
from r68k.
I can try to get a basic version of Capstone (68k disassembler part) in over the weekend and send a PR.
from r68k.
Ok, I'm thinking we should do that work in a dev-branch for now, I just created the "disassembler"-branch for this.
from r68k.
Sure!
from r68k.
I took a shot an an initial implementation yesterday, and got something I was not entirely unhappy with, by adding a disassembly module alongside the cpu module, but was really bugged by the fact that any trivial change there resulted in a minutes wait to recompile 12K lines of unrelated stuff (which after macro expansion seems to be more like 50K lines). I guess this is the non-incremental compilation showing its ugly head.
It made me want to rip out a few constants and other stuff to depend on, and work in an unrelated project, but I hope there's some better way.
You seem to have a much better grasp of cargo and crates than I have, so I wondered if there was some smarter way do divide stuff into crates or submodules in a way that would allow us to work on the disassembler, and let it use constants/enums/structs/traits that we've already defined without needing to recompile everything every time.
from r68k.
Also, I could push my WIP to the disassembler branch if you want to have a peek.
from r68k.
Sure!
from r68k.
Pushed now. I made a few constants and other stuff public in the old stuff, in order to be able to reuse it here. Also, I reused the LoggingMem to read ops out of "memory", but I guess that interface is not really useful if you are not disassembling a current r68k session with in-memory code.
Feel free to change any and all things as well, this was just to get this part going somewhere :)
from r68k.
what you could do is to split it up it to three separate crates
- Shared (constants/enums/etc)
- Emulator
- Disassembler
Now it would be possible to work "inside" the Disassembler crate only running cargo test
this crate would still be a lib so there wouldn't be a main function to run stuff in.
In that case it's possible to add things under the example directory inside the Disassembler
create and run them as cargo run --example some_example
if you would like a real main one can do a create outside called disassembler_test
or something that only depends on the Disassembler crate.
from r68k.
Useful command to run/visualize the test I did write; cargo test -- disassembler --nocapture
from r68k.
Yeah, I saw the --example
param somewhere a while ago and immediately thought it would be a good match for r68k! It really should be a library crate, I guess.
from r68k.
Before release it should be a library for sure (that is the way people would use it anyway)
from r68k.
Also I'm not sure if you have push the disassembler.rs
file
from r68k.
Oops, you are right. I'll be pushed shortly!
from r68k.
Now I pushed myself to push the missing file... ;)
from r68k.
👍
from r68k.
Also got some time to update the disassembler/assembler to a state where I'm happy with the design. If you're interested, take a look at either the disassembler branch, or the new library branch. I've yet to actually use capstone, but it was quite fun to get the disassembler/assembler working in concert (anything that can be disassembled should also assemble back to the starting opcode).
The disassembler/assembler just knows a subset of the ADD opcodes at this point. Adding more of the same kind of instructions (formats) with already implemented encodings should be trivial. Other instruction formats will need new decode/encode fn support.
The assembler is quite primitive, and extremely picky about syntax at the moment - it will basically only accept exactly the syntax that the disassembler generates. The parser is also completely regex based, which is probably not that efficient (saw extreme speedups when I started compiling complex regexes once, instead of once per opcode)
from r68k.
Cool. I would suggest looking at https://github.com/Geal/nom for parsing in the assembler.
from r68k.
Updated the assembler parser based on pest and it now parses the 10K lines of this basic interpreter in 68k assembly successfully(*), which is a big step forward, as the old regex-based parser was very limited, but the new parser accepts actual code. Note that while the parser is now good, the assembler itself still just supports a handful of opcodes.
I looked at nom, but found pest to be much more approachable.
*) Well, almost anyway. I decided to only support semicolon comments at the moment, so I edited the file slightly first, and it doesn't recognize the register lists of the movem instruction, nor the IF-statements (conditional assembly) yet. Movem needs to be supported when I get around to actually implement movem support in the disassembler/assembler - but conditional assembly is not a big priority at this point.
from r68k.
Related Issues (20)
- Implement TRAPV HOT 1
- Implement TST HOT 1
- Implement UNLK HOT 1
- Diff MAME version of Musashi with current HOT 29
- Compiler gets stuck when building release HOT 17
- Use default for Cpu struct
- More accurate cycle emulation for DIVS/DIVU needed?
- CHK, DIVU, DIVS trap case cycles differs from Musashi HOT 6
- Streamline qc and op_handler macros HOT 1
- Improve performance during QC HOT 27
- Improve QC coverage HOT 8
- Use a logging framework HOT 1
- Implement opcode completeness test HOT 5
- Consider using a codegen for glue HOT 2
- Generating cycle tables HOT 23
- Turn r68k into a lib HOT 14
- Host callbacks HOT 11
- Share fuzz testing code HOT 3
- fuzix HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from r68k.