From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Scott Lurndal  wrote:   
   >cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>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.   
   >   
   >I dunno.  We switched to C++ for operating system   
   >work in the late 80's, as did Chorus Systemes for   
   >their distributed microkernel.  The OS for Unisys' OPUS was   
   >a mix of C++, C and assembler (first and second   
   >stage boot loaders).   
   >   
   >Also used C++ for a bare-metal   
   >hypervisor in first decade of this millenium,   
   >and currently use it for CPU simulation along   
   >with SystemC.   
      
   Oh, I should apologize: I'm being lazily imprecise in that   
   I mentally lump C++ in with C for this problem domain, but I   
   never clarified that.  My bad!  Certainly C++ has been used in   
   the same general area for a while.  While in some respects an   
   improvement over C in terms of providing higher-level   
   abstractions, it is also a very idiosyncratic language and   
   notoriously complex.   
      
   >I suspect that had Rust been   
   >available when these projects started, it may have been a viable   
   >alternative, although being able to leverage   
   >and include existing C or C++ code was a valuable   
   >consideration in choice of implementation language   
   >in all the above projects.   
      
   Rust has good FFI interop with at least C (and, by extension,   
   assembler).  It is difficult to have completely faithful C++   
   interop without supporting the full semantics of C++ (SFINAE   
   and all of that), though there's been some good work on   
   increasing the set of common functionality: https://cxx.rs/   
   and https://crates.io/crates/cpp, for example.   
      
   I think Zig has a very good story here, perhaps better than Rust   
   in the way they integrate with a C compiler in addition to   
   supporting the local ABI.  E.g.,   
   https://ziglang.org/learn/overview/#zig-is-also-a-c-compiler   
      
   Back to Rust, though, I think there are still some gaps.   
   Support for writing C-style variadic functions is still not   
   stable yet: a program can consume a va_list, but not create   
   one.  When I wrote `printf` for rxv64, I wrote the base stub in   
   assembler, and then immediately delegate to a Rust function:   
   https://github.com/dancrossnyc/rxv64/blob/main/ulib/src/sysx86_64.rs#L109   
   At least robust support for a specified ABI gives us enough to   
   roll this.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)