muta...@gmail.com  wrote:   
   > On Tuesday, October 25, 2022 at 9:40:34 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > Thankyou for your informative reply!   
   >   
   > > > For starters, if an MSDOS executable has a function that   
   > > > crosses a 64k boundary, it will be tied down to a 4-bit   
   > > > shift, won't it?   
   > >   
   > > That depends how functions bigger than a segment are handled.   
   > > IIRC some (most ???) compilers required function to fit   
   > > into single segment.   
   >   
   > Sorry for my bad English. I expect the function itself to be   
   > less than 64k in size.   
   >   
   > > In principle compiler can split   
   > > function into multiple segments.   
   >   
   > It is the linker I am worried about. I believe it needs to add   
   > padding (x'00') before placing the code in the executable   
   > if the executable size is going to cross a 64k boundary   
   > while laying out the function (or maybe object file - I'm   
   > not sure).   
      
   That is routine problem.  For 8086 linker "knew" that segment   
   must start at address divisible by 16 and arranged executable   
   so that this was true.  On 286 (and 386) segment can start at   
   arbitrary address, so no extra problem.  In fact, for various   
   reasons addresses divisible by 16 are preferable, so placement   
   done on 8086 will work.  Of course, if you compiled code for   
   8086 you will have 1M limit on code, because in C you can not   
   dynamically create new code, so only data can benefit from   
   bigger address space.   
      
   > Also, this assumes that the hardware progressed at   
   > exactly the pace it had. If there had been a 200 year   
   > delay between the 80286 and the 80386, and a 500   
   > year delay between the 8086 and 80286, how would   
   > you develop the software?   
      
   I would code for 68000.   
      
   > Even though the 8086 was going to be there for 500   
   > years, it doesn't mean the clock speed wasn't going   
   > to change. It may have been fast enough to enable   
   > some solutions.   
      
   There are rules for chips which were observed in sixties   
   (and stated as "Moore law") which basically say that   
   both number of elements and clock freqency double every   
   few years.  That was related to physics and economy,   
   basically it is problematic to make very small chips   
   so chips size changed in limited way.  Number of elements   
   on chip is dependent on how small you can make them,   
   basically size of element squared gives you area of   
   element and you need enough area on the chip to put   
   all elements.  But also parasitic capacitance is proprtional   
   to element size and speed is inversly proportional to   
   parasitic capacitance.  In modern time rules about   
   speed do not work well,  namely there are two extra   
   limitations.  One is length of interconnect, once you   
   have a lot of elements on a chip connectiong wires   
   have large ratio of length to width.  Such wires have   
   limited speed.  The other trouble is due to heat,   
   if you scale naively each element consumes almost constant   
   power and once you have a lot of elements you have a   
   lot of power and there is risk of overheating.   
      
   Before 1990 one could get better clock speed by using say ECL   
   chips and special cooling systems, but that led to _very_   
   expensive machines.  Now, IBM was first to beat 5 GHz,   
   but even most extreme and expensive means give only moderate   
   speed increase.   
      
   > If we are having this discussion in 1955, you have no   
   > idea how fast computers are going to be in 1983.   
      
   In 1955 there was estimate that "well made" germanium transistors   
   should run at least to 600 MHz.  And in fact, such transistors   
   were available in sixites.  Given 600 MHz transiostor assuming   
   that signal in computer has to pass trough 30 transistors in   
   a clock we get about 20 MHz as possible clock speed.  During   
   WWII there were silicon diodes working at 25 GHz.  There is   
   no fundamental reason for silicon transitor to work significantly   
   slower than a diode (transistor is harder to make, so this is   
   manufacturing problem), so one could reasonably expect computers   
   with hundreds MHz clock.  I am not sure what was available   
   in 1983.  AFAIK there was Cray with single cycle execution and   
   80 MHz clock.  But in eighties there were buch of other   
   supercomputers, faster than Cray.   
      
   In a sense, more interesting is that there were _cheap_ computers,   
   at least cheap enough that ordinary person in developed country   
   could afford them.  In 1955 it was hard to predict such developement,   
   in 1963 we had IC-s and trend was clear.   
      
   > Segmentation as a concept could have been thought   
   > of in 1955 as something that might happen.   
      
   In a sense segmentation was something which was happening   
   in 1955.  Namely, important issue was managing access to   
   drum.  Drum was slow for random access, but allowed resonably   
   fast seqential reading.  Freshly discoverd core memory had   
   much faster random access, but much higher cost per byte.   
   So people were organising programs into "segements" so   
   that current segment was in core and when done it passed   
   control to next segment, fetched from drum.  Later discs   
   allowed bigger capacity at lower cost than drum.  Around   
   1970 paging won, it worked comparably or better than   
   manual segmentation and required no work from application   
   programmer (of course, you needed support in OS).  BTW,   
   paging was invented quite early (in fifties), but it took   
   some time to make it work well.   
      
   > > > Can you also confirm that CHS should never have been a thing?   
   > > >   
   > > > LBA should have been used from day 1.   
   > >   
   > > Well, passing from linear address to disc geometry requires   
   > > division. In 1982 disc contained no processor, so disc   
   > > had to get CHS info from OS. BIOS interface in theory   
   > > could accept linear addresses and turn them into CHS.   
   > > But IIRC division on 8086 took 150 clocks and you need   
   > > two of them for conversion. That 300 clocks is equvalent   
   > > to something like 50 simpler instructions, at that time   
   > > quite significant cost.   
   >   
   > Significant compared to waiting for a disk head to seek   
   > and retrieve the desired sector? Are you sure?   
      
   There is no warranty that you need seek.  BIOS in general   
   was rather slow, so this was probably premature optimization.   
   But could matter in better organized system.  In particular,   
   efficient system could do computations simultaneusly with   
   disc transfers (PC had DMA channels, so actual transfer   
   needed no CPU instructions).  Basically, if you request   
   data in advance they could be available when you need them.   
   Of course, neither BIOS or DOS handled this efficiently   
   (for me "the same" program under Linux run much faster than   
   under DOS due to efficient disc handling in Linux).   
   But if you want efficient system you need to start somewhere   
   and using CHS is "cheap" optimization.   
      
   > > So I can understand why CHS   
   > > was exposed to higher layers. IMO worst mistake was   
   > > that limits in number of heads in disc interface and BIOS   
   > > were different, that created trouble when disc reached 8G.   
   > > If done right CHS could work unchanged much longer and   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)