"Yes and no. Everything above the kernel level space is likely abstracted enough that you can compile it for a different target and be fine. It's everything at the kernel level that can't simply be compiled for another target as-is. Especially if it's poking at quirks of the ISA or in some cases, system requirements. For example, you can't load a bog standard amd64 build of Linux onto a PS4 despite the PS4 having an x64 processor. Why? Because the amd64 build of Linux still adheres to the IBM PC standard and expects things that the PS4 doesn't have because the PS4 wasn't designed to be IBM PC compliant."
Have you ever messed with the Kernel, it works as a sorting layer that is like indexing for an OS. For code outside an OS, which the actual execution code in assembly is, it is irrelevant. The Kernal is considered a high level code or mid level code that the software and hardware use to allow the OS to both monitor and keep track of the progress and timing of operations. The Old DOS games, like "syndicate wars" had no need for Kernels, and only because of the malpractice of Bill Gates, that he was litigated for, made an OS a prerogative to run most games (as its Kernel routed graphics calls through a HAL controlled by the Kernel.
Note, that until Windows Vista, previous versions of Windows could use the Kernel or have direct access to system resources (so you could effectively manually control the addressing of your hardware without Kernel interuption, and the Kernel would not interupt it, as your interuptions would have access directly to the IRQ's in the hardware. Then Bill decided that the Kernel would protect direct access to the resources and force everything to go through the Kernel (for Security apparently), even though now, because of this, anyone that hacks your Kernel can track every thing you do on windows at all levels.
Surprisingly Linux took that same approach, but as a superuser you can bypass its total control. And from time to time, updates can change your Kernel to a completely different format, to prevent hackers from learning and attacking the Kernel that is oh so much easier in Windows.
To prove my point, Look at the old game Syndicate Wars form 30 Years past. It had its own Renderer (made by Software programmers that understood hardware), it had complex 3D graphics with a twistable screen, wasn't limited to 32bit or 64bit memory addressing, but what the Programmers could decide based on Hardware detected, and had all of its own Kernel level driven control layer that worked seemless without all the problems that we face in modern games. People were inventive back then, and they proved that you didn't need generalised APIs or Kernels if you knew how to do it yourself. Now lazy engineers and coders have ruined innovation, and in Intel's case that shows with its failure to get 10nm running in a cost effective way.
So if you only thinking of the CPU having access to the accumulator as the control register, you are limiting the way in which the coding can be optimised. This also leads to this 'In order' and 'Out of Order' only, execution argument. My proposal would be to make more registers and have parallel loading registers that directly deal with the Conditional statements, dealing with the argument and both resolution at the same time (providing they are not nested), reducing countless MOV calls, and rather than handing off these conditional calls to the Cache, could have direct register access open to them.
New ISA's could also be made to deal with parallel computing better, rather than createing Kernels and other abstraction layers to sort out threads and execution.
Compilers, I see you dont really understand them. Compilers are made to avoid messing with the Kernel (apart from giving the essentail information to them), but why should that be? If you make a complete new ISA on an architecture, China could choose to have its compilers not only compile programs, but also compile Kernels in a modular way, Large Cache on Processors could hold the Kernels rather than having them offload on to the main RAM which is massively slower.
As always, the probelm is complexity and originality. AMD has competently proved that its R&D guys have this in spades per person more than Intel, but Intel has the money, and drives back innovation (like it did with SSEa and 3D now etc etc, and holds back innovation due to money.
The fact we have 4 different ISA's already means that making a new one is not difficult, rather than having to boost the same crap 8086 design and brute forcing it with speed and code to make things faster, when simple innovation and properly written compilers could offset that problem.
The cell processor was an example of this. It could have been a game changer, but the software engineers were to lazy and locked their function into set tasks, which not only wasted all the potential, but obseleted an optimised approach to Parallel computation with a single thread using multi core approach.
The limits are to the eye of the beholder and he who holds the intellectual property. And Intel is one of the biggest culprits of holding this back.
And yes, I do have enough knowledge to create my own CPU core using my knowledge of Digital, but like they did with the cell processor, even if I was to give it to them for Free, the lazy programmers would need to understand hardware (which most dont) to want to adopt its use. Hence they love Kernel's and API's, because it means they dont ever have to undertand the hardware.
Facebook
Twitter
Instagram