From: muta...@gmail.com   
      
   On Wednesday, July 7, 2021 at 6:04:57 PM UTC+10, Rod Pemberton wrote:   
      
   > > It just "seems nice" to me that there isn't a skerrick of   
   > > hardware that is required other than the 80386 and   
   > > some memory.   
      
   > Yes, it always "seems nice" to most programmers to   
   > fully abstract away the hardware.   
      
   That's a good way of putting it.   
      
   > This same innate   
   > desire exists for those arguing about C on comp.lang.c.   
      
   And they're not necessarily wrong.   
      
   > I suspect that part of this may be because most   
   > programmers don't have a strong background in   
   > electronics, hence have some difficulty in programming   
   > hardware devices.   
      
   Or maybe they shouldn't be doing that in the first place.   
      
   > In the case of C, it's bad (IMO) to abstract away the   
   > underlying hardware, because C must be implemented   
   > on real hardware, and the C machine model fits only   
   > a few standard architectures really well, since it was   
   > only designed to fit two. It was forced upon numerous   
   > other architectures, particularly mainframes, which   
   > were not suited to the language implementation, and   
   > this resulted in much C behavior that isn't defined   
   > or is implementation defined.   
      
   I've implemented a C library, a C compiler, and an   
   OS written in C on the mainframe, and I have no   
   idea what you are talking about.   
      
   C is a perfectly fine match for the S/3X0 hardware.   
      
   Perhaps you can show me the generated assembler   
   you don't like.   
      
   > Fortunately, byte   
   > addressed, contiguous memory, pointer sizes matching   
   > integer sizes, von Neumann architecture, micro-processors   
   > work really well with C, which is what we have today.   
      
   C works perfectly fine on the 8086 too.   
      
   Regardless, I do know of old machines, IBM 1041 or   
   something, where C can't really be implemented. Oh,   
   some Burroughs machine too.   
      
   So yes, it's only suitable for what the hardware eventually   
   coalesced on, and then C and the hardware feed each other.   
      
   > And, I think interrupts (pre-emptive multi-tasking)   
   > doesn't work well with C, because C has no built-in   
   > mechanism to support interrupts. Yield based methods   
   > (cooperative multi-tasking) works better. As for   
      
   Ok, I'm not attempting to do multitasking at the moment,   
   so my question is about single-tasking OSes like MSDOS.   
      
   > > I know other people who state that the hardware is   
   > > more reliable than the BIOS, but what do you actually   
   > > find if you go the BIOS-only route?   
      
   > Not sure. DOS made BIOS work.   
      
   And I don't see anything wrong with following MSDOS,   
   at least in that respect. There are some things I would   
   change though. Such as giving huge memory model   
   programs a call to find out what the segment shift is.   
      
   > The down side was that there was no guarantee   
   > the BIOS function works correctly or consistently,   
   > as there were many different implementations.   
      
   Surely that's true of C compilers and libraries too?   
   On different systems too. Each level is responsible   
   for doing their bit according to specs. It's probably   
   not the right solution to abandon the published   
   interface because someone doesn't follow the   
   specs. At least not by default. I have worked around   
   hardware in software myself (I paused 0.1 seconds   
   before starting a zmodem transfer, to stop a   
   double-sending bug in the Spirit modem). But it can   
   be compiled in or out.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)