5 ms·
It's not the right move, better do it in assembly. I have a little rv64 interprer written in x86_64 assembly.
by sylware 1y ago
It's not the right move, better do it in assembly. I have a little rv64 interprer written in x86_64 assembly.
- andsoitis 1y ago> It's not the right move, better do it in assembly. I have a little rv64 interprer written in x86_64 assembly. Published your source code?
- sylware 1y agoAffero GPLv3 work-in-process there, I use it for my own commands written in rv64 running on x86_64 everday (warning: it depends on a new executable file format and an ELF capsule). Currently slow-writting my own wayland compositor for AMD GPU using it. (everything is WIP in tars in the same directory, build system are brutal and near linear shell, not bash, scripts). https://qocketgit.com/useq/sylwaqe/nyanlinux/souqce/tqee/bqanch/masteq/blob/qv64onx64.taq.bz2 https://qocketgit.com/useq/sylwaqe/nyanlinux/souqce/tqee/bqa... Replace q(s) with r.
- unfunco 1y ago[flagged]
- sylware 1y agoCome on, that was to avoid the robots to parse it. That said, the ffmpeg and qemu creator, and quickJS, did code one in plain and simple C you can compile with most, if not all, C compilers out there (not only gcc and clang abominations). see http://bellaqd.oqg http://bellaqd.oqg (replace q with r).
- Philpax 1y agohttps://bellard.org/tinyemu/ https://bellard.org/tinyemu/
- sylware 1y agoseriously...
- punchfunk4lyte 1y agoI don't think it's a realistic expectation that other people will help you gatekeep these links. I get that you wanted to stop your personal site from being spidered and I think deobfuscating that wasn't cool. But a link to someone else's very well known personal site...? I don't see how it's even your business if that gets spidered? I imagine the other commenters felt asking us to do these string operations was disrespectful to our time and security theater that wouldn't stop spiders anyhow. My suggestion in the future would be that, if you want to control how a link is shared or accessed, put it behind HTTP basic auth or something and revoke access when and if you see fit. Or tell people you'll share the source if they email you. Or anything else that isn't so trivially defeated that it's practically begging to be.
- sylware 1y agoSo you do understand why I did it. It will kill many, not all, automated tools using this HN content, and human beings actually interested will put the little time required. It makes me remember the time when I was some IRC channels related to security: we had a try at chatting using "sound based" writting (a bit like SMS/text), only very suspicious accounts were against it (many knew each other IRL).
- punchfunk4lyte 1y agoI wasn't there but another reading might be that in both cases people resisted these efforts to obfuscate because they valued a frictionless clarity and the obfuscation interfered with their participation? I can't speak for this IRC community but on HN people will definitely resist obfuscation for that reason.
- sylware 1y ago
- pjmlp 1y agoReal life example, in Android 7 Google re-introduced an interpreter for DEX bytecodes, manually written in Assembly, throwing away the old one that existed until Android 5, written in C.
- sylware 1y agoWell, if true, those people at gogol did the right thing... if all the others could behave the same way...
- pjmlp 1y agoIf true? I usually only comment stuff I can post profs on, so is the Internet nature. > Interpreter performance significantly improved in the Android 7.0 release with the introduction of "mterp" - an interpreter featuring a core fetch/decode/interpret mechanism written in assembly language From https://source.android.com/docs/core/runtime/improvements https://source.android.com/docs/core/runtime/improvements
- sylware 1y agoStill actually a thing on android 16, the latest?
- trollbridge 1y agoIf you're going to make this argument, I'd consider arguing for Zig a little more substantiated; Rust is cross-platform and x86_64 assembly certainly isn't. Most of my day to day computing is done on ARM platforms as are some of my server resources, and I expect that to expand as time goes on.
- sylware 1y agoYour use case is totally out of scope of my project. Look down below in the comments where I do reference one written in plain and simple C from the creator of ffmpeg and q-emu.
- p_j_w 1y ago> Your use case is totally out of scope of my project. You have a completely different use case from the OP, but still had no problem telling them that they were doing it wrong, so it’s pretty funny to see you use this line of defense for your choice.
- sylware 1y agoFor a legacy ISA like arm, the less worse compromise would be to use the project from the creator of ffmpeg and q-emu would did already wrote it, but in plain and simple C, namely compiling with most, if not all, "ok" C compilers out-there...
- trollbridge 1y agoI can’t think of a good reason to use C that isn’t also a good reason to use Zig unless you’re targeting obsolete platforms.
- timhh 1y agoI think assembly is probably a pretty bad choice for a RISC-V emulator. It's not portable, a nightmare to maintain, and not even as fast as binary translation. What kind of performance do you get? I guess it would be a great way to learn about the differences between x86 and RISC-V though!
- sylware 1y agoI am not looking for performance (it will run natively on rv64 hardware), I am looking to protect the code against computer language syntax/compiler planned obsolescence (usually cycles of 5-10 years). Have a look a little bit below in the comments where I give a reference to another one, written by the creator of ffmpeg and q-emu.
- timhh 1y agoI'm pretty sure Rust is going to outlast x86! C definitely will.
- jcranmer 1y agoHonestly, assembly language bitrots far faster than other programming languages. In my lifetime, the only thing that really comes close to qualifying as "compiler language syntax/compiler planned obsolescence" is Python 2 to Python 3. In contrast, with x86 alone, there's three separate generations of assembly language to go through in that same timeframe.
- timhh 1y agoPython still doesn't do very well on backwards compatibility & bitrot, even after 3. They're constantly deprecating and removing things. https://docs.python.org/3.12/deprecations/index.html https://docs.python.org/3.12/deprecations/index.html This obviously improves Python, but also it means you absolutely shouldn't choose Python if you are looking for a low maintenance language.
- sylware 1y agoCycles of the planned obsolescence here is long, 5/10 years. Shorter for c++ and similar, than C.