Conversation

Notices

1. Santa Claes 🇸🇪🇭🇰🎅 (clacke@libranet.de)'s status on Tuesday, 13-Aug-2024 11:09:25 UTC Santa Claes 🇸🇪🇭🇰🎅

   LoongArch / LoongISA, looking up further details Re: social.treehouse.systems/@aria…

   en.wikipedia.org/wiki/Loongson…

   The binary translation instructions have the specific benefit of speeding up Intel x86 CPU emulation at a cost of 5% of the total die area. The new instructions help a QEMU hypervisor translate instructions from x86 to MIPS with only a reported 30% performance penalty.

   
   That's very interesting in the context how our ISAs will look in 100 years, how we handle legacy, the thread about Itanium the other day, etc.

   The thing with "Programmer at Large" where our interstellar trade fleet 1000 years from now runs all these legacy systems in x86 emulators never fully leaves my mind.

   • Leif Lindholm (unixsmurf@mastodon.social)'s status on Tuesday, 13-Aug-2024 11:09:24 UTC Leif Lindholm

     in reply to

     @clacke
     Not convinced. If anything, C is very detached from the underlying hw (while simultaneously being a high-level assembler)? Hence all the UB.

     Even x86 managed to migrate ABI from "everything is on the stack" to err, "no, actually, registers are worth paying for".

     Santa Claes 🇸🇪🇭🇰🎅 likes this.
   • Santa Claes 🇸🇪🇭🇰🎅 (clacke@libranet.de)'s status on Tuesday, 13-Aug-2024 11:09:25 UTC Santa Claes 🇸🇪🇭🇰🎅

     in reply to

     "The thread about Itanium" is this one, lamenting the lack of exotic CPUs and how we're trapped in C-driven ISAs, which traps us in C, which traps us in C-driven ISAs:

     libranet.de/display/0b6b25a8-8…

     If you support C in a performant way, you stay commercially viable. One way to still innovate is to glue two ISAs together, which I believe is what the #itanium did.

     LoongISA is showing another way; extending the ISA with some help instructions without fully emulating in hardware. I wonder if the C compiler for LoongISA benefits from these x86 help instructions even when compiling native C.

     It sounds like I'm equating x86 and C here, but I'm not really. I do assume though that MIPS is less C-driven than x86, which I assume is severely C-driven. Please jump in if that's all wrong.