https://github.com/xoreaxeaxeax/movfuscator
And also REpsych from the same developer which really isn't for the fainthearted...
[1] https://github.com/xoreaxeaxeax/movfuscator
[2] https://harrisonwl.github.io/assets/courses/malware/spring20...
https://github.com/xoreaxeaxeax/movfuscator
Presentation of idea:
https://github.com/xoreaxeaxeax/movfuscator
Since this is effectively branchless and every instruction would take the same number of micro ops, wouldn't this be a very safe way of writing cryptographic code free of side channels?
This model makes the assumption that all players in the value chain (producers and consumers) are agents with repeatable instructions ie put,Get,push,add,mov,etc.
Since there is No SI unit for instructions I propose the Unit for measuring instructions be MOV operator , This is because of my belief taking inspiration from the X86 MOV operator which was proven to be turing complete with the movfuscator(https://github.com/xoreaxeaxeax/movfuscator). What this means IMO all computable operations can be broken down to move operations.
Lastly this system views markets as interaction between agents . And makes the assumption that agents that do not sustainably price their goods / services will fail to operate in the longrun. And views variance / volatility in prices as a outcome of chaotic interaction between agents rather True indicator of value.
This model is completely different than market analysis of prices / value . Not to mention that majority of value traded is done outside of open markets .
This model makes the assumption that all players in the value chain (producers and consumers) are agents with repeatable instructions ie put,Get,push,add,mov,etc.
Since there is No SI unit for instructions I propose the Unit for measuring instructions be MOV operator , This is because of my belief taking inspiration from the X86 MOV operator which was proven to be turing complete with the movfuscator(https://github.com/xoreaxeaxeax/movfuscator). What this means IMO all computable operations can be broken down to move operations.
Lastly this system views markets as interaction between agents . And makes the assumption that agents that do not sustainably price their goods / services will fail to operate in the longrun. And views variance / volatility in prices as a outcome of chaotic interaction between agents rather True indicator of value.
Structured programming is not just a syntax sugar: the restriction encourages more readable programs https://blog.acolyer.org/2016/10/13/go-to-statement-consider...
And if we're being silly, you only really need mov[1].
mov rax, [table + rax*8]
mov [table + rax*8], rax
Even better, there are multiple encodings of those instructions. And even better than that, there are Turing-complete subsets comprised only of printable ASCII characters. And even better than that, there are subsets of x86 the instruction set that can masquerade as readable English text: https://news.ycombinator.com/item?id=16312317
If your program counter ever diverges off to start executing unsanitized user data on x86, you are potentially pwn'd.
Previous submissions with significant discussion:
- https://news.ycombinator.com/item?id=18991404
- https://news.ycombinator.com/item?id=16218872
- https://news.ycombinator.com/item?id=12372242
movfuscator
"The single instruction C compiler"
https://github.com/xoreaxeaxeax/movfuscator
...In other words, yes, it is possible to write a complete compiler which creates all of its compiled code by using only one single type of x86 instruction...
Also, this might be interesting:
https://en.wikipedia.org/wiki/One-instruction_set_computer
>"A one-instruction set computer (OISC), sometimes called an ultimate reduced instruction set computer (URISC), is an abstract machine that uses only one instruction – obviating the need for a machine language opcode.[1][2][3] With a judicious choice for the single instruction and given infinite resources, an OISC is capable of being a universal computer in the same manner as traditional computers that have multiple instructions.[2]:55 OISCs have been recommended as aids in teaching computer architecture[1]:327[2]:2 and have been used as computational models in structural computing research.[3]"
See this presentation, too: https://www.youtube.com/watch?v=R7EEoWg6Ekk
Or you decide to execute code on The Fungus: https://www.bedroomlan.org/hardware/fungus
I also recall reading a paper that got into implementing a GC on silicon for a graph rewriting based architecture
WebAssembly is if/else blocks. There's a potential future where it gets implemented directly as a CPU ISA (albeit it'd likely involve some dynamic translation, but the CPU may decide to have SSA as its internal representation)
It's important to understand there's a real distinction between semantics & implementation. Otherwise you risk emulating your implementation when some new hardware comes out (say GPUs, or Quantum computers, or out of order CPUs working backwards to create something like SSA for register renaming/pipelining, or cmov)
See also the debates over C code being executed in the C abstract machine for optimizers while programmers rely on implementation of the end result. But in a language without undefined / implementation-defined behavior you won't have these ways of having the program self observe its implementation
https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/REpsych
Only move instructions
Malloc isn't particularly more special than any libc function. It simply supports the fantasy that the memory is unlimited in scale. It was always of a static size, you were just handing off the chore of dividing it up. You can usefully implement dynamic sizing in languages with static memory allocation by pre-allocating large arrays and then maintaining handles and liveness flags. This is, in fact, how every console game used to do it until available memory sizes got into the hundreds of megabytes. Fragmentation and the subsequent crashes from OOM presented too much of a concern before then.