From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Scott Lurndal  wrote:   
   >cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>In article <4O84M.509173$cKvc.254869@fx42.iad>,   
   >>Scott Lurndal  wrote:   
   >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>>>In article ,   
   >>>>Luke A. Guest  wrote:   
   >>>>>On 02/05/2023 02:30, Dan Cross wrote:   
   >>>>>> For decades the operating system development landscape has been   
   >>>>>> dominated by C; specifically in the kernel space.  In so many   
   >>>>>> ways, this makes sense, as C was created to build an operating   
   >>>>>> system, but it's also become an increasingly hostile language   
   >>>>>> for its original purpose (e.g., https://arxiv.org/abs/2201.07845   
   >>>>>> and https://queue.acm.org/detail.cfm?id=3212479; others).   
   >>>>>   
   >>>>>It was always a hostile language.   
   >>>>   
   >>>>I can see why people say this, but what I mean is that compiler   
   >>>>writers have become somewhat hostile to OS developers by really   
   >>>>stretching what "Undefined Behavior" allows them to do.  I get   
   >>>>that on some level, but on another, it means that one cannot   
   >>>>treat C as a portable macro assembler.  Indeed, this has been   
   >>>>the case for decades.   
   >>>   
   >>>The C compilers generally used for OS development have flags   
   >>>to disable the aggressive optimizations.   GCC is, after all,   
   >>>still used to build linux and several other operating systems   
   >>>and hypervisors.   
   >>   
   >>This is true.  However, once one goes that route, one finds that   
   >>one is no longer writing in C, but in a dialect of C specific to   
   >>some project.  Granted, that dialect shares syntax and _most_ of   
   >>the semantics of C, but it's a dialect nonetheless.   
   >   
   >I would argue that there has never been a single dialect of   
   >C - even today one cannot write a useful and well performing   
   >application using just the facilities of standard C (toy   
   >programs, educational exercises, yes, real programs, not so   
   >much).   So we have two primary dialects, POSIX and Windows.   
      
   I'm not sure I agree with that first statement.  One could write   
   `grep`, for instance, using pretty much only pure ISO C.  But   
   yes, as soon as you move out of the domain of simple filters,   
   the landscape is far more complex.   
      
   I think this all reinforces my thesis, by the way: there are now   
   reasonable alternatives to C.  Why then, would one prefer C to   
   another language?  I assert that, for many application domains   
   where it has been the de facto default, it is no longer the   
   best choice.   
      
   >When I started getting paid to write operating systems, they   
   >were primarily assembler (e.g. VMS, with some in BLISS-32);   
   >Burroughs was the exception by using a dialect of Algol   
   >as a systems programming language.   HP did something similar   
   >on the HP-3000 with SPL.   In both cases, the languages were   
   >designed to be close to the hardware.   
   >   
   >In the early 1980s Burroughs developed a language called   
   >SPRITE for the BCD medium systems line - we rewrote the   
   >1960's assembler MCP in the modula-like SPRITE language,   
   >but even there facilities needed to be provided for low-level   
   >machine access (privileged instructions, multithread   
   >synchronization mechanisms, access to special hardware   
   >registers (e.g. the base of the translation tables), etc).   
   >   
   >Granted in in all the above cases, the compiler team   
   >sat across the hall from the OS team and there were no   
   >agressive optimizations of UB behavior as there was no   
   >UB behavior.   
      
   C certainly started in this vein: pre-typesetter C for writing   
   Unix on the PDP-11 was, in a lot of ways, very close to the   
   machine.  Where it wasn't (direct access to machine state like   
   registers, or invoking privilieged instructions), it had easy   
   interoperability with assembler.  This is still largely true.   
      
   >>But personally, I'd rather program in a language that requires   
   >>well-defined behavior by default, coupled with semantics that   
   >>make it aggressively optimizable.  In Rust, for example, the   
   >>compiler simply prohibits UB outside of `unsafe` blocks: it is a   
   >>compile-time error.  Moreover, `unsafe` blocks aren't permitted   
   >>to contain UB; rather, the compiler simply gives the programmer   
   >>a little more leeway to perform actions that it cannot tell are   
   >>safe, and shifts the onus onto the programmer to ensure that   
   >>the program is well-defined.   
   >   
   >We'll see if Rust is the answer long-run.   As long as it   
   >has the facilites noted above, it should suffice.   
      
   It does.  The rxv64 kernel and C library are all in Rust, with a   
   bit of assembler thrown in.  The user programs are still in C,   
   though.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)