vroom VS movfuscator

Maybe implement a big feature for a open source design? like vroom or xiangshan.

The two most micro architecturally advanced cores that I know of are BOOM, an out of order RV64GC core with all the features you expect plus sort of weird fancy things like short forward branch predication, and VROOM, another out of order RV64GC core with things like uop fusion and a trace cache.

I had VROOM! in mind (https://github.com/MoonbaseOtago/vroom) because I remembered it aims for 4 IPC avg with a width of 8. Though looking again it's 8 compressed 16 bit instructions or 4 uncompressed 32 bit instruction.

So you could argue a real mix of instructions is not going to be all 16 bit but some 16 and some 32, so the 8 is rarely achieved in practice, and also the block diagram only shows 4 decode blocks. But it can in fact peak at 8 instructions decoded per clock, so I think that qualifies. (You could even argue it's especially impressive, since RISC-V technically qualifies as variable-length encoding like x86, it's just that only 16/32 instructions are really used at the moment)

If you are interested in high performance look into vroom , c910 and xianghan, maybe you could adopt one of them.

On top of what others mentioned (Red Hat) , it is also possible to go with the mysql/mariadb model of dual licensing, you can have a copyleft license where you must contribute back changes, but also allow selling an proprietary license if they want to enhance it but not share the improvements (like amazon or Ampere Computing that enhance ARM designs and sells it for servers), there is already a RISK-V implementation that aims to do that (vroom). another option is a non profit foundation that companies contribute to because they use the project and want it to be better (like the linux foundation) , risc-v has similar nonprofits like the chips alliance (which develops the Rocket-Chip ) or the OpenHW Group (which develops CVA6), there is also lowrisc which develops ibex (but as far as i can tell isn't governed by the contributing companies like the other non profits).

You want a very optimistic answer? someone is working on open source server core, It is already announced and i have been told it is somewhere around four years for a chip to ship after announcement so i would say 4 years from now.

At the moment the Apple M1/M2 are the king of wide decode. Within a couple of years you will see equally wide decode and execute of RISC-V from companies such as Rivos, or indeed open source and GPL'd projects such as VROOM! (https://github.com/MoonbaseOtago/vroom)

> True performance RISCV designs are going to be people's money maker and never open sourced.

That turns out not to be the case.

Alibaba's C910 core -- roughly comparable to the ARM A72 cores (at the same MHz) in the Pi 4 -- is open sourced. It is being used, at 2.5 GHz, in the upcoming "Roma" laptop. That is rather expensive (for now), but I suspect the same TH1520 SoC will quickly find its way onto cheaper SBCs.

There is a very wide OoO GPL'd RISC-V core that is under development. It is aiming for eventual Apple M1 level performance. The current iteration is falling short of that at the moment, but it's already comparable to the ARM A76 in the latest RK3588 SBCs: https://github.com/MoonbaseOtago/vroom

Then you can help open source hardware designs like xiangshan or vroom.

Everything can be reduced to assignments. https://github.com/xoreaxeaxeax/movfuscator

However, the movfuscator as implemented does still require a sigaction(2) syscall to set up a signal handler, under the justifications that "it is not actually part of the program" and that "if we were in ring 0, we wouldn't need help from the kernel" [0]. However, the latter part seems a little dubious to me: without the help of the kernel running non-MOV instructions, you'd never be able to escape from 16-bit real mode into 32-bit protected mode, since you wouldn't be able to load a valid GDT with the LGDT instruction (as far as I am aware).

[0] https://github.com/xoreaxeaxeax/movfuscator/blob/90a49f31219...

I _think_ the idea is thinking of an "interface" as "something that you use as a way to interact with something from outside an abstraction". I'd summarize their argument as reasoning that if the goal of an abstraction is to avoid having to care about the internal details of something, an interface is a way to expose a subset of ways to interact with it, and the more you expand it, the more it exposes the internals of the thing being abstracted. I don't think they necessarily mean this only in terms of programming, but you could apply this argument to a programming language interface; if you use an interface for interacting with something instead of its direct functionality, each additional method you add to the interface exposes more details of the inner value, which makes it less of an abstraction.

Assuming my interpretation is correct, I'm not sure I totally buy this argument because there doesn't seem to be an obvious way to define the "size" of an interface where it holds true. The naive way to define the size would be number of methods, but I'd argue that methods can vary so much in terms of the amount of cognitive overhead they "expose" to the user that it's not very meaningful. Consider the Movfuscator compiler[0], which compiles code into binaries only using MOV x86 instructions because it happens to be Turing complete; as complex as it might be to learn x86 assembly as a whole and start writing programs directly in it, I'm dubious that trying to do so only with MOV would somehow be easier. Put another way, an x86 instruction set that only contains the MOV instruction is not a "stronger" abstraction than the actual one because it _introduces_ complexity that doesn't exist in the original. Does adding an ADD instruction alongside MOV increase the strength of the abstraction, or weaken it? I don't think there's an answer that we'd immediately all agree on for this sort of thing.

Ultimately, I think trying to measure interfaces through the number of methods they expose is similar to trying to measure code by the number of lines in it; while there are some extreme cases where we'd likely all agree (e.g. for a fizzbuzz implementation, having 10 lines of code is probably better than thousands of lines of code[1]), we can't really come up with a good objective metric because the "target" number is based on the complexity of what you're trying to define, and we don't have a way of quantifying that complexity. I think the ideas here are still super interesting though, not because they have definitive right or wrong answers, but because thinking about stuff like this overall improves one's ability to write good software for usage by other programmers.

[0]: https://github.com/xoreaxeaxeax/movfuscator

The mov instruction in x86-64 is Turing complete. Someone even made a C compiler using only mov.

Are you sure they didn't use the MOVFUSCATOR?

Yep. In fact you can reduce everything to just one simple assembly instruction.