While very(!) cool as a proof of concept,
This type of solution should probably be avoided for security, stability and portability reasons.
Allowing a string in your program to be dynamically converted to assembly code, copied to executable memory and be executed is a remote code execution security hole just waiting to happen.
I'm wondering what the use cases for this were, and if they couldn't be achieved in another way.
Seriously? It says a lot about the direction computing is going when one of the first things someone says upon seeing one of the most powerful and amazing things you can do with a general-purpose computer is some fearmongering about a "remote code execution security hole". The "oppose anything that could possibly be used in some way someone doesn't like" attitude is why computers have become so user-hostile. :-(
Protecting the safety, security and privacy of users isn't "user-hostile".
Leaving your users exposed to hackers, viruses, malware, malicious adware, ransomware, government espionage and bot networks is.
I find it completely baffling than in 2016, people can still refer to writing secure code as "fearmongering".
Being able to dynamically inject code into your process and run it is indeed very powerful.
But i'll cliche quote spiderman about great power, and insist that if you're going to execute "mprotect" or "VirtualProtect", make sure the code you're about to execute is signed and verified.
Not doing so, would be user-hostile.
From the scasm readme.md: "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics."
Isn't security one of those interesting topics?
It can be... but it also can be a drag if that's not your immediate area of study. Security is incredibly important, but it is an overhead: including a cognitive overhead. If I'm futzing around with a toy project to learn about how, say, distributed agents can make use evolutionary selection to create efficient protocols amongst themselves (yes, a completely bullshit set of terms strung together) and I fully expect this to never leave a group of VMs on a home server.... yeah, security is NOT something I'm going to sweat. Doing so would be a distraction and counter-productive to my goals.
To be fair to your point, however, by not constantly practicing secure coding techniques, regardless of context, I could get out of the habit of secure coding as a default. I may simply not think about it at a time when I should be. By always considering, even in my bullshit toy project, I stick to my good practices and more consistently apply them when it counts. But the argument that security coding can be interesting and fun is not a good enough argument to care about it all the time.
I'd argue that all code should be fairly defensive.
Security flaws in the end are just bugs. And defensive programming helps reduce bugs.
As for toy projects - you never know when your futzing around becomes a full blown product.
Obviously, security is always a tradeoff. I'm not suggesting you implement 2 factor authentication for your wedding invite website. But it does always help to consider:
1. How can this code break, if someone accidentally misuses it?
2. How can this code break, if someones intentionally misuses it?
Very often, thinking about #2 can help resolve a lot of things overlooked in #1.
Jailbreaking and modding are probably the main cases where users choose to exploit arbitrary code execution bugs on themselves, often to bypass DRM protections.
You're right. missed the "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics." at first. You'll see I addressed this later on in the thread.
I tend to skim through the readme and dive in to the code when evaluating stuff on github.
Well for this specific `add` function, no it won't :)
The hotspot compiler will generate the same code anyway (perhaps even more optimised if it is possible I don't know). Worse, this code would probably be inlined while the `native` version won't.
Not only will the native version not be inlined, the JIT will also have to insert an annoying amount of stuff round it to handle calling conventions and other fun things.
http://video.fosdem.org/2016/h2214/amd64-assembly-programmin...
https://github.com/bdw/lab/tree/master/asm