NeoISA

as i already described in my home page, my doubts that a new isa is really needed are getting stronger and stronger. every isa is per se the access to the hardware behind it and its architecture. abstractly seen, however, they are more similar to each other than some people like to think, because most of the work is still in aluminium, comparison and jumps. with risc still loading and saving, and with scientifically based programs still floating point operations. what happens, when we try to keep an isa alive for compatibility reasons, can be seen best on the x86 isa. instead of cutting off old habits, because they hinder future developments, many things are held on to for said compatibility reasons, which have a strong negative influence on the hardware, the performance and therefore the power consumption. on the other hand, a cpu needs machine code, which it can execute. and this is where the neo approach starts.

intermediate language

marek and i had endlessly discussed exactly these thoughts, that a generally valid intermediate language is needed, such an abstract isa, which still contains enough information to translate it into a target isa with all the possible and necessary optimizations. but all language relevant and other optimizations should be done before. so the time consuming optimizations would be done and the sourcecode would not be recognizable anymore, which is still very relevant for many companies. from today's point of view it was all about generating a DAG. unfortunately we hadn't followed this concept any further.
but as soon as you wait a few decades, something like this already exists. the intermediate languages of the compilers of gnu and llvm are exactly what we needed at that time.
so why don't we take exactly one of these as isa?
that's exactly the discussion i would like to have. what's stopping us from using llvm-ir, because i'm more into llvm than the ultimate distributions isa? if operating systems would be compiled not to x86 or arm, but to llvm-ir, then it wouldn't matter what the cpu behind it would look like. the same for programs, drivers, apps, whatever. all of them would generate llvm-ir code. which they do when they use llvm to compile, but then they go a step further and translate it into the target architecture. exactly this last step can be left to the manufacturer of the hardware. he could then translate the llvm-ir code into the specific architecture required by the manufacturer in a transmeta-like way. the manufacturer would then have the freedom to adapt this architecture to the needs of the market at any time. e.g. in data centers a different architecture could be used than in general working home computers, or in tablets or telephones.
the manufacturer could then use a very special compiler in his devices, which only supports the hardware used to the maximum. future findings on performance improvement could also be updated. security problems are also easier to get to grips with, because there is no possibility to execute machine code directly, and the llvm-ir code can be tested before it is translated.

pre bios or microkernel or nanokernel

in contrast to transmeta, i imagine to establish a mini operating system, which takes care of translating, caching and executing the llvm-ir code. important is, that it is a technology, which offers maximum security. i personally tend to say that it would be useful to establish a microkernel, which is the abstraction layer to the important resources. small and absolutely stable, like a l4 or better a sel4

linux with llvm-ir

as a hard nut to crack, the next step would be to try to get a linux kernel running. the nice thing is, that there is a variant of the linux kernel, which runs under a l4, the l4-linux. because the biggest challenge by far will be to get rid of machine code from current programs. also the linux kernel has some parts of machine code, but in the l4 variant it is almost gone, and so there is almost nothing in the way of the linux kernel to run it under llvm-ir. the charming thing about it is, that llvm is already very mature, has accordingly few bugs, is fast, very modular, offers different languages, offers different targets cpu's, and with lli has an llvm-ir interpreter/jit, with which you can start right away.

well, that's the idea behind neoisa. not a new isa, not a really new idea, nothing really innovative. nevertheless, i think that if there is a possibility to establish something like this, it offers a huge potential for further hardware developments, which are not based on a special isa anymore and can be very agile.