From: quadibloc@ca.invalid   
      
   On Fri, 06 Feb 2026 16:37:00 +0000, John Dallman wrote:   
      
   > Isn't that going to create opcode space pressure?   
      
   Well, that will be less of an issue in an architecture where the   
   instructions are stored in wider memory.   
      
   > How are you planning to handle UTF-8, UTF-16 and UTF-32 character data?   
   > Creating UTF-9, UTF-18 and UTF-36 seems like pointless complexity.   
      
   I think UTF-9 was described in an April 1st RFC. But I agree with that.   
      
   Essentially, I am now thinking that a CPU with this architecture might   
   have its primary application as a numerical co-processor for a   
   conventional CPU. This would provide the opportunity for carrying out   
   computations with extra exponent range or higher precision without having   
   to switch to a much larger floating-point format, thus avoiding loss of   
   speed.   
      
   One would need to create a new kind of RAM module to support a 144-bit   
   wide data bus, but it would be unrealistic to create new video cards and   
   so on.   
      
   So it would have its own FORTRAN compiler - that would be the highest   
   priority in software development, after some kind of operating system for   
   the compiler to run within. Well, maybe porting a C compiler would need to   
   come first, to allow everything else to be ported.   
      
   John Savard   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)