I’ve been a fan of this article for years, though it does often make me think that there really aren’t any true low level languages for our super scalar modern CPUs. Does anyone know of any?

▲

aDyslecticCrow 3 hours ago | parent | next [-]

The article does make an example quite early;

> GPUs achieve very high performance without any of this logic, at the expense of requiring explicitly parallel programs.

GPU cores are in some ways closer to "PDP-11", they're either acting as thousands of parallel simple processors, or expose pretty raw instructions for very parallel use-cases.

▲

legobmw99 3 hours ago | parent [-]

That seems fair, CUDA kernels and shader code do feel like they're at a similar level of abstraction over the hardware as C was to the PDP-11. But I do think there isn't really an equivalent for modern CPU ISAs

▲

aDyslecticCrow 3 hours ago | parent [-]

Mabie hand-rolling LLVM IR representations would count.

	▲	jpollock an hour ago \| parent [-]
		Doesn't assembly allow devs to ignore speculative execution as well? You can place LFENCE(x86)/CSDB(arm) around code blocks, but you can do that in C too.

▲

melodyogonna an hour ago | parent | prev | next [-]

The thing is, you can only program what is programmable. If a CPU has some capability that isn't programmable, I don't know what C or any other language is expected to do.

▲

giancarlostoro 3 hours ago | parent | prev | next [-]

Probably Mojo, it doesnt just talk to your CPU it also will talk to your GPU bypassing the need for CUDA. Its early days, but I see strong potential in Mojo. Currently its primary focus is GPUs for AI inference, but give it a year or two and it will be really interesting for more than just that.

▲

kllrnohj an hour ago | parent | next [-]

In the case of this article, even assembly isn't low level. It's not possible at all to write low level code for a modern superscalar CPU.

So no, Mojo wouldn't be low level. It can't be.

	▲	CalmDream an hour ago \| parent [-]
		A bit of a nitpick, but from the article: "A low-level language for such processors would have native vector types of arbitrary lengths." Mojo has exactly this with the SIMD struct: https://mojolang.org/nightly/docs/std/builtin/simd/SIMD/

▲

huijzer 2 hours ago | parent | prev | next [-]

Mojo to me seems like a high level language with some additional support for low level control especially around GPUs. A bit like Rust or C but with more streamlined Python integration and more low level GPU (matrices) support.

▲

3 hours ago | parent | prev | next [-]

[deleted]

▲

poly2it 3 hours ago | parent | prev [-]

But Mojo is a high level language?

▲

ferguess_k 3 hours ago | parent | prev | next [-]

Wondering can we write microcode? That's definitely closer to the metal.

	▲	wat10000 2 hours ago \| parent [-]
		That was kind of the original idea of RISC. Expose simple instructions that could be implemented without microcode. Push the complexity into the program instead of the microcode. Instead of writing a memory-to-memory add instruction that decomposes into load, load, add, store microcode, you directly write the load, load, add, store. This didn’t quite work out in the long term since hardware evolves faster than ISAs. Today’s “maps directly to the hardware” instruction is tomorrow’s “we add more hardware and play tricks to make this faster.” You explode all of the physical registers as logical registers, then a few years later you double the physical registers count and do clever mapping to extract more speed. My favorite is the MIPS branch delay slot. Instead of complicated branch prediction to hide latency, expose the pipeline directly to the programmer. And then a couple of hardware generations down the line, the pipeline becomes much longer and more complicated and the CPU is back to playing tricks to hide latency, and the weird branch delay slot remains as essentially a vestige of bygone days.

▲

jjtheblunt 3 hours ago | parent | prev | next [-]

> really aren’t any true low level languages for our super scalar modern CPUs

do you mean low level but higher level than assembly language for those processors (like MIPS assembly for an R10k, for example) ?

▲

MrBuddyCasino 3 hours ago | parent | prev | next [-]

In what way would exposing the true microcoded out-of-order etc nature of the beast benefit certain tasks?

▲

legobmw99 3 hours ago | parent | next [-]

Better control over the async nature of the hardware is part of what makes GPU kernels efficient, but I'm not terribly sure the same thing would be the case on the other side of the PCIe bus.

But even before you get to out-of-order/speculative execution, I think most languages lack good (i.e. non-intrinsic-based) support for wide registers or anything SIMD related. I know C++ and Rust are both working on this

▲

12_throw_away 2 hours ago | parent | prev [-]

It's a good and interesting question, why is it important whether or not it will "benefit certain tasks"? And how would we even know if we haven't tried it?

	▲	jjtheblunt an hour ago \| parent [-]
		VLIW investigated this idea, where the compiler took responsibility for scheduling multiple functional units at compile time, in contrast with dynamic reordering as in superscalar. https://en.wikipedia.org/wiki/Very_long_instruction_word

▲

glouwbug 3 hours ago | parent | prev | next [-]

[dead]

▲

lelanthran 3 hours ago | parent | prev [-]

[flagged]