From: cr88192@gmail.com   
      
   On 9/14/2025 9:06 AM, Michael S wrote:   
   > On Sun, 14 Sep 2025 10:19:08 -0000 (UTC)   
   > Thomas Koenig  wrote:   
   >   
   >> Michael S  schrieb:   
   >>> On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)   
   >>> Thomas Koenig  wrote:   
   >>>   
   >>>> Michael S  schrieb:   
   >>>>> On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)   
   >>>>> Thomas Koenig  wrote:   
   >>>>>   
   >>>>>> Similarly, rounding modes are saved and restored for   
   >>>>>> procedures.   
   >>>>>   
   >>>>> I am not sure that I understand.   
   >>>>> 1. Is Fortran's equivalent of C's fesetround() is considered a   
   >>>>> languge primitive rather than procedure?   
   >>>>   
   >>>> Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),   
   >>>> procedures from intrinsic modules, like COMPILER_OPTIONS   
   >>>> from ISO_FORTRAN_ENV, and user-defined procedures.   
   >>>> IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module   
   >>>> (but an optional one).  It need not be an external function;   
   >>>> the compiler is free to do other things to implement it.   
   >>>>   
   >>>> (Hope this answers your question)   
   >>>>   
   >>>   
   >>   
   >> OOOPS.   
   >>   
   >> Seems I misread the standard, missing out on clause 17.4 paragraph 5,   
   >> which states   
   >>   
   >> In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS,   
   >> the processor shall not change the rounding modes on entry, and   
   >> on return shall ensure that the rounding modes are the same as   
   >> they were on entry.   
   >>   
   >> So, that part of my premise was wrong. Sorry.   
   >   
   > Now it sounds like matching Kahan's intentions.   
   >   
   >   
      
   So, this implies the rounding mode and similar are expected to follow   
   dynamic scoping rather than global scoping?...   
      
   May need to work on this some more if so, but it appears that a lot of   
   existing C compilers treat it as global?...   
      
      
   I guess things also come up with ISA choices.   
      
      
   Can note, for example:   
      RISC-V always has a 3-bit rounding mode in the instruction;   
        GCC defaults to 7 (dynamic);   
        BGBCC uses 0 (RNE) or 7 (DYN), depending on FENV_ACCESS   
      XG1/2/3 have multiple several versions of some of the instructions:   
        FADD/FSUB/FMUL   : Hard-wired RNE (no status flag updates)   
        FADDG/FSUBG/FMULG: Dynamic Rounding Mode (updates flags)   
        FADDA/FSUBA/FMULA: Reduced Precision   
          Binary64 format, but mimic Binary32 precision.   
          No flags updates.   
      
   It is possible to give a full static rounding mode (like in RISC-V), but   
   this requires a 64-bit encoding. Static rounding other than RNE is very   
   rare though.   
      
      
   But, yeah, I have now noticed that my attempt to add an IEEE exact mode,   
   due to pipeline timing issues in my Verilog code, was generating   
   spurious Emulation-Request traps, which in some cases was causing   
   problems (occasionally random data on the pipeline managed to cause the   
   FPU to occasionally generate an FPU exception whenever using an FPU   
   instruction due to whatever had been in the pipeline before the   
   instruction in question was performed; regardless of the state of the   
   IEEE-754 emulation flag).   
      
   Had to fix this and then re-upload the Verilog core as I noted that this   
   bug leaked into the version I had posted online.   
      
   Also there was another related bug where FPU instructions in interrupt   
   handlers could effect the FPU flags visible in userland. I ended up   
   adding a mechanism to partly disable both the flags behavior and traps   
   when inside an interrupt handler (so, interrupt handlers will always get   
   DAZ/FTZ and similar).   
      
   But, yeah...   
      
      
      
   Otherwise:   
      
   Some people in RISC-V land now jumped onboard with adding Load/Store   
   Indexed and similar (and auto-increment, blarg). Their encodings clashed   
   with my Load/Store Pair, but ended up resolving the issue partly by   
   relocating my definition of LDP/SDP entirely over to the FLQ/FSQ   
   instructions (my core not implementing the Q extension, so FLQ/FSQ could   
   also be used for LDP/SDP).   
      
   In the newest variant, even numbers will encode FPU pairs, as before,   
   whereas Odd numbers encode GPR pairs. This is kinda backwards, but   
   minimizes code breakage (and allows a grace period for the proposed   
   encodings to "not break stuff"); though does still leave some "breaking   
   changes".   
      
      
   Have noted that currently code compiled with RV-C enabled in BGBCC is   
   crash prone with my VL core; whereas code compiled with GCC seems to   
   work. May require more investigation (did recently start trying to make   
   use of more of the RV-C encodings in BGBCC, so maybe stumbled on   
   something here).   
      
      
   Had also been working on getting some previously unimplemented parts of   
   XG3 working (such as support for predication). One part that was causing   
   problems was that BGBCC was using some stale encodings (from earlier in   
   the design of the encoding scheme). Seems also there was a bug where it   
   was trying to use the predication encoding rules on jumbo-prefixes.   
      
   Still not fully working yet though.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)