Conversation
|
|
||
| armv7_bench_defaults = { | ||
| "arch": "armv7", | ||
| "filename": os.path.join(root_dir, 'input', 'tdfx_dri.so'), |
There was a problem hiding this comment.
i suppose i didn't commit it.. i stole a reasonably chunky .so out of x11 after crawling through debian armv7 packages. i was hoping to find an armv7 version of xul.dll, but no one builds firefox for aarch32 anymore... but there's probably a more directly comparable object for armv8 at least :3
There was a problem hiding this comment.
Debian seems to have ARM32 builds of Firefox as well:
http://ftp.us.debian.org/debian/pool/main/f/firefox/firefox_144.0-1_armhf.deb
Though it's also fine with me to use that other lib that you referred to above.
|
Happy to include ARM disassemblers as well! I'm not really familiar with the library landscape around 32-bit ARM, and Capstone is the only other one that comes to mind. In case you also want to do aarch64 benchs, for that one I've always used V35's library previously: https://github.com/yrp604/bad64 I've also started working on an aarch64 Zydis port last year, and actually wrote a whole parser and for their machine-readable documentation and pseudo-code, but honestly all the legal foo on the doc about not being allowed to redistribute the info in any form got me sufficiency intimidated that I didn't go through with it. Discovered it a bit late in the process unfortunately.
Yeah, I think I'd either make it different plots or at the very least make it a subplot in the same PNG. |
2 participants
been kind of idly wondering about this since #5.. a few months ago i'd taken a more careful look at
yaxpeax-arm's armv7 throughput and ended up kinda hacking something together. i haven't bothered to wire up other disassemblers (yet??), capstone would be a pretty clear alternative option here.@athre0z how do you feel about including ARM disassemblers? and maybe at this rate, RISC-V in another eight years :) i'm 50/50 on this myself.. but maybe a
bench-x86.pngandbench-arm.pngcould be clearly separated in the README and it could be neat? totally defer to your taste.