From: cr88192@gmail.com   
      
   On 10/13/2025 11:29 PM, Janis Papanagnou wrote:   
   > (Sorry for the delayed reply; your ~450 lines post was too long for   
   > me to consider a timely reply.)   
   >   
   > On 09.10.2025 05:49, BGB wrote:   
   >> On 10/8/2025 2:04 PM, Janis Papanagnou wrote:   
   >>> On 08.10.2025 19:29, BGB wrote:   
   >>>> On 10/8/2025 8:59 AM, Janis Papanagnou wrote:   
   >   
   >>   
   >> Throughout much of my life, C++ has been around, but using it has often   
   >> turned into a footgun. Early on the code had a bad habit of breaking   
   >> from one compiler version to another, or the ability to compile C++ code   
   >> in general would be broken (primarily with Cygwin and MinGW; where   
   >> whether or not "g++" worked on a given install attempt, or with a given   
   >> program, was very hit or miss).   
   >   
   > I used it early on on various Unix platforms; all had some details   
   > different - like the way how templates worked in the development   
   > environment - but nothing was really an issue; as with current   
   > configuration settings this was covered and handled by the build   
   > system.   
   >   
   > It doesn't astonish me the least if you've faced specific problems   
   > on the Windows platforms.   
   >   
      
   It was pretty variable, but usual thing was that trying to build any   
   kind of C++ code (even a trivial "Hello World") would on some installs   
   of these compilers, simply die in a storm of error messages.   
      
   Well, and for a given Cygwin install attempt, whether or not "g++" would   
   work, etc, was a bit like playing roulette.   
      
      
   After switching to MSVC, things were a little more stable here.   
      But, by then there were other issues.   
      
      
   >> [...]   
   >>   
   >> In most cases, it left C as a more preferable option.   
   >> C can be made to do the same stuff at similar performance, with often   
   >> only minimal difference in expressive power.   
   >   
   > The problem is, IMO, rather that "C", in the first place, doesn't   
   > compare to C++ in its level of "expressive power".   
   >   
      
   ?...   
      
   I have yet to find much that can be expressed in C++ but is not also   
   expressible in C.   
      
      
   The main things that are fundamentally different, are things like   
   Exceptions and RTTI, but even in C++, these don't come free.   
      
   Though, if exceptions are implemented using an approach similar to VEH   
   in the Windows X64 ABI, it is at least modest.   
      
      
   >>   
   >> And, the main "powerful" tool of C++, templates,   
   >   
   > (IMO, the main powerful tool was primarily classes, polymorphisms,   
   > also [real] references.)   
   >   
      
   These can be done in C via manually written vtables, and passing the   
   address of a variable.   
      
      
   >> tending to do bad   
   >> things to build times and result in excessive code bloat.   
   >   
   > I recall that initially we had issues with code bloat, but I don't   
   > recall that it would have been a problem; we handled that (but,   
   > after that long time, don't ask me how).   
   >   
   >>   
   >> And, if one tries to avoid C++'s drawbacks, the result was mostly code   
   >> that still looks mostly like C.   
   >   
   > (That sounds as if you haven't used OO designs, reference parameters,   
   > overloading, and so on, obviously.)   
   >   
      
   We can do OO, just using a different approach, say:   
      typedef struct FooObj_s FooObj;   
      typedef struct FooObj_vt_s FooObj_vt;   
      struct FooObj_vt_s (   
        void *resv1;   
        void *resv2;   
        void *resv3;   
        void *resv4;   
        int (*Method1)(FooObj *self, int x, int y);   
        int (*Method2)(FooObj *self, int x, int y, int z);   
        ...   
      };   
      struct FooObj_s {   
        FooObj_vt *vt;   
        int w;   
        ...   
      };   
      
   And, references as:   
      int someFunction(int *rvar);   
      ...   
      someFunction(&somevar);   
      
   It all works, and doesn't require significantly more LOC than it would   
   have in C++.   
      
      
   >>   
   >> 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.   
   >   
   > IME, *writing* software in "C" requires much more time than in C++;   
   > presuming you meant that with "most efficient way to do things".   
   >   
   > (Saving a few seconds in "C" compared to C++ programs can hardly be   
   > relevant, I'd say; unless you were not really familiar with C++ ?   
   > Or have special application areas, as I read below in the post.)   
   >   
      
   Main limiting factor at present is that it is a harder issue to write a   
   non-trivial C++ compiler.   
      
   I could write C++ code, but then it isn't really portable outside   
   running on my PC or similar.   
      
      
   Though, I have a mostly usable C compiler at least.   
      At least, usable for porting single programs.   
      Trying to port something like the Linux userland, not so much.   
        Too much stuff here is written to assume GCC.   
      
   Some simple programs worked with "./configure" scripts and getting it to   
   mimic GCC enough that configure will try to use it as a cross compiler,   
   but then programs invariably break when trying to use various GCC'isms   
   or trying to rely on glibc specific stuff or other Linux specific   
   headers or so on.   
      
   So, yeah, nowhere near up to the level of trying to deal with trying to   
   port "bash" and "coreutils" and similar.   
      
   But, was able to experimentally port things like "Quake 3 Arena" and   
   similar, though Q3A is a little impractical on a 50MHz CPU; but Doom   
   runs well.   
      
      
   Granted, a new language would not really address and of the "make   
   existing software work" issues.   
      
      
   >> [...]   
   >>   
   >> 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.   
   >   
   > "Nice. - I've done Neural Net simulations with C++ back these days.)   
   >   
      
   I have experimented with some, but in this case mostly using a lot of SIMD.   
      
      
   I had noted that in some cases, like primarily SIMD heavy NN code, my   
   50MHz FPGA soft-processor could compete surprisingly well with an early   
   2000s laptop.   
      
      
   But, then again, also noted by benchmarking said laptop:   
      memcpy: ~ 450 MB/sec;   
      x87 multiply-accumulate: ~ 60 MFLOP.   
      CPU speed: 1400 MHz, 32-bit x86.   
        Has MMX and similar, but was not using MMX.   
        Had noted the process is mostly bandwidth limited.   
      
      
   The SIMD unit on my soft-processor has a theoretical hard-limit of 200   
   MFLOP, but if using compact formats (mostly FP8 for storage, FP16   
   internally) and careful pipelining, can approach similar performance to   
   the laptop at this task.   
      
   I had experimented some with more compact encodings for weights, for   
   example:   
      FP8U A/B (E4.M4)   
      3-bit per value: S,FF (S=Sign)   
        A<=B: Interpolated: A, B, (5/8)A+(3/8)B, (5/8)B+(3/8)A   
        A> B: Similar, but '111' encodes 0, ...   
   With interpolation as bytes, results unpacked into vectors of 4x   
   Binary16 (with 4 weight vectors in 64 bits).   
      
   Could also be used as:   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)