XorA wrote:For me, figures like this prove again that ideas of native hardware with Raspberry as coprocessor are pointless.
I would have to agree with Peter on this.
And AROS (Amiga Research Operating System, an AmigaOS 3.1 compatible OS) proves you can take and old 68k OS and "convert" it to other CPUs. It even automagically runs a 68k emulator for old executables so they function on the new CPU seamlessly.
The point here seems to be that AmigaOS is mainly written in C and only minimal 68K assembler. That probably explains the portability to other CPUs.
At the turn of the century, I provided proof of concept for QL native TCP/IP mainly written in C and was still so motivated that I wanted to make it part of SMSQ/E. Back then, it was politically impossible, both by a proprietary OS license and style/tool restrictions solely allowing assembler code. By now, these restrictions have been removed. It seems unlikely that we still have enough development manpower and motivation today, but in principle I find a defined way to add C language portions to SMSQ/E an interesting thought!
Not only for TCP/IP, also GUI for example. Some have seen a demonstration at the Edinburg meeting 5 years ago, a native GUI with proportional fonts, rounded shapes and theming. Yet another unfinished one-man project, but it shows how much more we might have today, if C language was nicely usable for parts of the OS.
I suspect similar advantages for C when it comes to hardware driver writing. All my machines from Q40 to Q68 were developed with (mainly) C language drivers written by myself. Even QL-SD ran only my own C code at first. That code was later rewritten in assembler. But without C language code as starting point, I guess none of those pioneer projects would have ever gotten driver support. If the need to (re)wite driver code in assembler was removed, it might encourage new hardware.
Can we learn from AmigaOS in this regard? Or would the SMS/QDOS system interface work too inefficiently in combination with C language code?