On 11/14/20, 1:49 AM, "cctech on behalf of Adam Thornton via cctech" <cctech-bounces at classiccmp.org on behalf of cctech at classiccmp.org> wrote: Hi Adam, Possible architectures beyond x86 we're keeping an eye on are ARM and RISC-V, but they'll need to start doing a lot better in the datacenter before it'll be worth our while. So far, ARM in the datacenter hasn't taken off the way many predicted it would. One thing I'm better at than crystal ball gazing though, is I can give you an idea of how much hard-to-port assembly is left, since I wrote most of the x86 assembly code in it :-) With the port to x86, we made a conscious effort to minimize the amount of code written in assembly; so at this point, it's pretty much limited to code where (a) we can't use the stack, or we need to manipulate the stack pointer in a non-standard way; (b) we need to use a special instruction that we don't have a compiler builtin for (these are mostly cases where an instruction is only used in one place); and (c) code that needs to mix calling standards - i.e. the code shims necessary to interact with the UEFI firmeware. Category (a) is obviously the more interesting one, and that includes things like code that is responsible for switching between VMS' four modes (kernel, executive, supervisor, and user mode), and context switching for the schedulers (OS scheduler, kernel process scheduler, and POSIX threads scheduler). The OS scheduler is a good example of our effort to eliminate assembly code. On VAX, Alpha, and Itanium, the scheduler loop and the idle loop (which performs maintenance tasks such as dirty page zeroing) were written in assembly, and re-written with each port. For x86, I rewrote these in C, using small assembly helper routines only in the critical parts where it couldn't be avoided. In total, there are 30 modules that were written in x86-64 assembly. I'd classify 10 of those are trivial, 16 as average, and 4 as complicated and difficult. The complicated and difficult category contains code responsible for dispatching system services, handling interrupts and exceptions, delivering ASTs. As much design and work was involved in those assembly modules though, a whole lot of x86-specific work was done for the MACRO-32 compiler. MACRO-32 originated as the VAX assembler, and while it is a compiler on other architectures, it is still much like an assembler, and specific translations from the VAX instruction set to the target architecture need to be made. The MACRO-32 compiler talks to the LLVM code generator backend at a lower, more instruction-centric level than the compilers for higher languages, and this work is very x86-64 specific. Given that about 1/3 of the OS is written in MACRO-32, we won't get rid of MACRO-32 code in the OS any time soon. (The other 2/3rds are written in BLISS and C) Also, in the C, Bliss, and MACRO-32 code, lots of conditionalizations are made on architecture. Certain things are done differently on Alpha than they are on Itanium, and on x86 we sometimes do things the way we did them on Alpha, sometimes the way we did them on Itanium, and sometimes we need to come up with an x86-specific way. So, the port to x86 has made a future port to ARM or RISC-V easier; particularly by moving to the LLVM code generator backend, and by figuring out how to run a four-mode OS on a two-mode architecture without sacrificing the benefits of running in four modes; but it has by no means made it trivial. Camiel