mbitsnbites

Alpha (1990s) had something along those lines called PALcode. Also check out the term "millicode" (IBM system/390, also 1990s).

It's probably higher level than you are asking for, though.

The ISA is actually there as an abstraction layer, to allow CPU manufacturers to innovate "under the hood" w/o breaking software compatibility (serves roughly the same purpose as an API).

Giving programmers direct access to the inner workings of a CPU would mean that the software would only work on a very specific model (e.g. work fine on AMD Zen 2, but crash and burn on AMD Zen 3), since lots of things change from model to model (e.g. number of pipelines, instruction latencies, ALU implementation details, etc).

Worth noting: Some DSP ISA:s are quite close to "the metal". They are designed for maximum energy efficiency, and thus sacrifice some "convenience" functionality such as hardware hazard resolution (e.g. stall pipeline until result is reasy), meaning that the compiler needs to take care of instruction scheduling etc.

Update: I just moved the scalar register file to block RAM, and now the pipeline uses ~1800 ALMs, or 9% of the chip logic.

I'm still learning FPGA:s myself, so I'm not sure if I can give you a relevant figure. Currently the A1 pipeline (no memory subsystem) synthesises to 2000-3000 ALMs (or about 15% of the logic in the device I'm targeting). That will increase as I implement more instructions (the FPU in particular), but on the other hand it will probably decrease when I switch to using BRAM for the scalar register file.

Thanks for the reference - I have not heard about the Convex C-Series before so I'll be sure to look it up.

While the MRISC32-A1 does serial vector processing, the idea is that you should be able to do parallel processing with the same ISA, so I'm not certain that masking in that fashion is a good option for the MRISC32. Also, having a vector mask register like the Cray limits the size of the vector registers (e.g. to 32 elements in the MRISC32, or 64 elements in a 64-bit architecture).

I suspect that what you say is true. One thing worth considering though is that on x86_64 you actually use the vector register file for floating point (and it can do integer too!).

On the MRISC32 you have a vector register file with 32 registers that can easily be configured to do scalar operations (integer or floating point) by setting the vector length to 1.

Yes, I've seen it. It's quite neat. On the other hand it seems more complex to implement in hardware.

In the simplest possible design, the cost of vector support in the MRISC32 is essentially the cost of the register file (i.e. the register memory), since the vector control logic just consists of a few adders and flip-flops, and the scalar execution units can be reused for vector operations.

SSD types: for the machines that are identical, they are the same

Linux filesystem: stock ext4

That's the easy case. In a typical enterprise environment a software developer may be faced with several roundtrips to the centralized/outsourced it support to get their build folders white listed in the company approved (and forcibly installed) AV software to make a simple CMake run take less than 10 minutes (something that takes about 5 seconds on a stock Linux machine).

I didn't think that these benchmarks would get this much attention. I personally made them because I could not believe that identical Windows and Linux machines were performing so different in typical software development tasks (Git, CMake, GCC, file copying, ...). I threw in a few more machines (Raspberry, Mac, ...) into the mix to get some perspective.

Most machines were stock configured (Ubuntu ext4 install for Linux, Windows 10 w/ Windows Defender, macOS X stock install, etc), so I believe that they should be representative for average users.

The benchmark suite is open source and easy to run on your own hardware if you like to get more accurate/representative figures for a particular setup.