From: cr88192@gmail.com   
      
   On 10/9/2025 7:13 PM, bart wrote:   
   > On 09/10/2025 04:49, BGB wrote:   
   >> On 10/8/2025 2:04 PM, Janis Papanagnou wrote:   
   >>> On 08.10.2025 19:29, BGB wrote:   
   >   
   >> Though, similar was often a problem in my other language design   
   >> attempts: The most efficient way to do things was often also the C way.   
   >>   
   >>   
   >>   
   >> The only real exception I have found to this rule basically being in   
   >> relation to some features I have borrowed from languages like GLSL and   
   >> Verilog. But, some of this stuff isn't so much making the language   
   >> "higher level" as much as "being easier to map to ISA features and   
   >> optimize".   
   >>   
   >> Say:   
   >>    vd[62:52]=vs[20:10];   
   >> Being easier to optimize than, say:   
   >>    vd=(vd&(~(2047ULL<<52)))|(((vs>>10)&2047ULL)<<52);   
   >   
   > Using special bit-features makes it easier to generate decent code for a   
   > simple compiler.   
   >   
   > But gcc for example has no trouble optimising that masking/shifting   
   > version.   
   >   
      
   BGBCC is not so clever...   
      
   Granted, its code footprint is tiny vs GCC, and it can do a full rebuild   
   in a few seconds (with effectively the entire "compiler toolchain" in a   
   single binary).   
      
   Like, GCC and LLVM are both very large (over 10M lines).   
      
   Contrast, BGBCC is still in kLOC territory.   
      
      
   Granted, still not that small, still pretty big if compared with   
   something like Doom; but alas, I haven't really been able to fit a C   
   compiler into a Doom-like code footprint (say, trying to keep a C   
   compiler under 30k lines).   
      
   I did start making an attempt at one point, but ended up dropping the   
   effort after I have already exceeded a Doom-like code footprint, and it   
   still wasn't very close to being done.   
      
   Is a little easier with an interpreter, but if one wants sensible native   
   code generation, doing it within a small footprint is difficult.   
      
      
   So, as-is, I have a compiler that is roughly around the size of the   
   Quake 2 engine...   
      
      
   > (It can do it in four x64 instructions, whereas I need nine working from   
   > vd.[62..52] := vs.[20..10]. It could be improved though; I don't need to   
   > extract the data to bits 10..0 first for example.)   
   >   
   > The main advantage is that it is a LOT easier to write, read and   
   > understand. The C would need macros to make it practical.   
   >   
      
   Shifts/Masks and macros is more traditional, but as noted, with my   
   compiler explicit bit notation is easier to optimize, as well as read   
   and write.   
      
   >   
   >> Though, Verilog itself, not so much... Works well in an ASIC or FPGA,   
   >> not so much on a CPU.   
   >>   
   >> Though, as can be noted:   
   >>    Bit-ranges are required to be constant at compile time;   
   >>    When used with normal integer types, both bounds are required.   
   >   
   > I can handle some variable elements, but it gets rapidly complicated. At   
   > some point it needs to use library functions to do the work.   
   >   
      
   In my case, I only allowed constant ranges here.   
      
   If runtime calls were used, they would eat any possible savings.   
   But, the ability to generate efficient code here falls on its face if   
   non-constant.   
      
      
   >>   
   >> OTOH, GLSL offers nice and efficient ways to deal with SIMD.   
   >> Well, and also having some types for bit-preserving casts.   
   >> Or ability to specify endianess and alignment for individual struct   
   >> members.   
   >> ...   
   >>   
   >>   
   >>>>   
   >>>> Granted, a few of my own language design attempts ended up with a   
   >>>> different mess:  [...]   
   >>>   
   >>> A sensibly defined language isn't something easily to create   
   >>> or obtain! - Personally I'd have appreciated it more if more   
   >>> designers of "own languages" have oriented their designs on   
   >>> sensible existing and proven concepts. - There may be a   
   >>> "market" for all these "own languages", I don't know, but I   
   >>> also don't care much, given what I've seen or heard of yet.   
   >>> (This isn't meant to be offensive, just to be clear, only   
   >>> that I don't care much. As compiler writers don't care much   
   >>> what I think.)   
   >>>   
   >>   
   >> Yeah.   
   >>   
   >> They have either tended to not amount to much, or converged towards   
   >> more conventional languages.   
   >>   
   >>   
   >>   
   >>>> [ attempt for a discussion on features of "own language"   
   >>>>    snipped; not my business ]   
   >   
   > (There are those who can devise and use their own languages, and those   
   > who can't.)   
   >   
   >> Some amount of my stuff recently has involved various niche stuff.   
   >>    Interfacing with hardware;   
   >>    Motor controls;   
   >>    Implementing things like an OpenGL back-end or similar;   
   >>    Being used for a Boot ROM and OS kernel;   
   >>    Sometimes neural nets.   
   >   
   > Some impressive stuff.   
   >   
      
   Yes, and mostly C domain.   
      
      
   I have my own experimental ISA which was partly designed with the   
   intention of using it for a mix of motor controls and computer vision.   
      
   Mostly I have just ended it for running ports of 90s era games (and   
   otherwise mostly using ye olde ARM). Partly, one is still hard-pressed   
   to get an FPGA to be performance competitive with something like a   
   RasPi; and a RasPi is cheaper.   
      
      
   But, for my own ISA, did end up writing the firmware and OS (including   
   OpenGL) using my own compiler, although mostly in an extended C dialect.   
      
      
   And, using my C compiler as:   
   I could throw it together for my own ISA and design experiments;   
   GCC or Clang would have been too much of an uphill battle;   
   LCC would still have left me needing to do most of the relevant work myself;   
   ...   
      
      
   If comparing against GCC targeting RV64, my stuff gets better   
   performance (though, BGBCC typically loses if both compilers are limited   
   to plain RV64G; but my compiler with my ISA can beat GCC when GCC is   
   limited to RV64G).   
      
      
   Though, With a few carefully selected extensions, RISC-V can be brought   
   into a similar performance profile as my own ISAs:   
      Indexed Load and Store;   
      Load/Store Pair (load or store pairs of 2 registers at a time);   
      Jumbo Prefixes (can expand immediate values from 12 to 33 bits).   
      
   In some programs, this combination can get a 40-60% speedup over plain   
   RV64G.   
      
   A lot of other things are possible, but the gains are generally a lot   
   smaller.   
      
      
   As I can note, ISA list supported by my compiler looks kinda like:   
      SuperH: SH4   
        BJX1 (an extended variant of SH4).   
          (Split into several variants)   
        ( Not currently maintained )   
      BJX2 (Current ISA family)   
        XG1: Original form of the ISA   
        XG2: Intermediate form   
        XG3: Reworked to coexist better with RISC-V.   
      RISC-V   
        RV64G/RV64GC   
        Various optional extensions.   
      
      
   While RISC-V exists and is popular, not fully jumped over to RV as in   
   its basic form, its performance is a little weak (partly due to weak   
   areas and "foot guns"). Its performance can be improved, but there are   
   limits.   
      
   The XG3 variant is promising, but is essentially XG2 and RV64G just sort   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)