Aardvark Daily

Please visit the sponsor!

Taking programming languages out of the loop

The first computers were designed with programmers in mind.

Although the instruction-sets of those early computers were clearly constrained by the hardware technology available at the time, they were also structured so as to make programming easier.

A limited number of registers, instructions and addressing modes made writing software much easier when there were no high-level languages and the code had to be hand-assembled from op-codes into raw binary, octal or hexadecimal values.

Compilers of the day had to make do with targeting instructions that were more built for humans than automated translation from the likes of BASIC, C, Pascal or whatever into the binary data that constituted the actual running code.

However, things then began to change.

With faster processors and more memory becoming the norm, cutting assembly code by hand was no longer desirable nor necessary. This triggered something of a change in CPU design.

Instead of focusing instruction-sets around what programmers find useful and easy to use, processors began to focus on the instructions that make compilers and the code they generate more compact and efficient.

The result was a gradual but noteworthy improvement in compiler performance and the resulting code was more compact and faster.

Of course we designed and implemented these computer languages because they make a programmer's job much easier. All elements of a program's design and implementation could be abstracted and dealth with at a higher level than mere CPU instructions and data bytes.

Now however, we're entering an age when even high-level languages (HLLs) like Java, Python, Rust, etc., are no longer as important as they once were. Instead, we simply ask a LLM agent to create code for us.

Right now, those agents tend to create their vibe-code in one or more of the traditional HLLs and pass that on to existing compilers for program-code generation. I'm picking that won't continue for much longer though.

Why bother having an unnecessary middle layer of human-readable source code written in an HLL when, once properly trained, our AI systems could have the ability to cut machine-level code directly?

Indeed, it would make sense to get AI to figure out exactly what instructions would be best suited to direct-code creation and also design processors to handle those instructions directly.

The result would be faster creation of more efficient code that ran faster and required less memory in which to do so.

This is the ultimate end-point of this instruction-set evolution and could effectively give us another significant leap in performance without having to add more cores or hike clock speeds. It would also allow systems to function better even with less available RAM, something that could be really important now that most of the world's RAM production is being swallowed up by AI datacenters.

Even as traditional HLL programmers are being cast on the scrapheap, thanks to AI, the potential for ongoing improvements in computer performance would seem to be significant, thanks to stripping out the middle-layer of coding and optimising processors for direct AI-generated executable code.

Carpe Diem folks!

Please visit the sponsor!

Here is a PERMANENT link to this column

Rank This Aardvark Page

Change Font