muta...@gmail.com  wrote:   
   > On Wednesday, October 12, 2022 at 7:37:43 PM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   > > muta...@gmail.com  wrote:   
   > > > On Wednesday, October 12, 2022 at 9:33:38 AM UTC+8, anti..   
   @math.uni.wroc.pl wrote:   
   >   
   > > > > Coming back to modes: main problem with modes is that various   
   > > > > applications "live in different words", you can not simply   
   > > > > call function in binary library compiled for different mode,   
   > > > > you need to recompile or have some wrapper code handling   
   > > > > mode switching.   
   > > >   
   > > > Not correct. C-generated code doesn't manipulate the   
   > > > segments at all - and even in huge memory model the   
   > > > manipulation can be done by an OS-provided routine   
   > > > so that it works in protected mode too.   
   > > >   
   > > > It will be completely unaware that a shift value of 5 is in effect.   
   >   
   > > I do not think so. Note that I wrote "binary". If you have   
   >   
   > Yes, my comment is about binary.   
   >   
   > > source you can recompile and machine architecture does not   
   > > matter.   
   >   
   > I'm not interested in source.   
   >   
   > > If you have binary, even output of a C compiler you   
   > > can not make assumptions about output, AFAIK all C compilers   
   > > allow programmer enough freedom to break rules.   
   >   
   > Ok, we're talking cross purposes. Sorry, I probably   
   > have 50 unstated assumptions, and I don't know how   
   > to spell them all out upfront.   
   >   
   > I only care about programs that obey the rules and   
   > are either bug-free or the vendor is willing to fix   
   > the bugs.   
   >   
   > Also I'm not a commercial CPU vendor and I'm not   
   > trying to generate a profit.   
   >   
   > I'm trying to get a handle on the underlying theory.   
      
   Theory is simple: if program treats segments in abstract   
   way, that is does not attempt to use aritmetic to   
   produce new segment selectors, then it will work with   
   no problems in 286 protected mode.   
      
   In practice, it did not work -- your (and Intel) assumptions   
   were not valid.   
      
   > > Now, look at   
   > > a C string "Hello" : at machine level in large mode it is   
   > > represented by segment and offset pair, say 4a86:8086. In   
   > > function using segment shift 4 it points to different memory   
   > > area than say segment shift 5 would give. So, to have ability   
   > > to call you need single value of segment shift. But if you   
   > > try to run binary created for one segment shift value,   
   >   
   > There is no such thing as a binary created for one   
   > segment shift value. If such a thing exists, I   
   > consider it to be a bug, and it is not relevant.   
   >   
   > > Murphy   
   > > law says that it will not run with different value, unless   
   > > programmer did extensive testing with both value.   
   >   
   > Computers don't obey Murphy's Law. And if a programmer   
   > didn't test with every possible shift value from 0 to   
   > 16, I don't care. I'll report bugs as I find them. It's   
   > just like any other bug they may have.   
   >   
   > > To put   
   > > it differently, single bad spot can break program and you need   
   > > enough testing to ensure that no such bad spot.   
   >   
   > There's no such thing as "enough testing".   
   >   
   > > Concerning huge mode: having function call for array indexing   
   > > is performance killer, people who care about performance   
   > > issues would not accept this.   
   >   
   > Huge memory model is a performance killer already. That's   
   > why it is rarely used. If someone wants to request a   
   > binary with a hardcoded segment manipulation (out of the   
   > many possible) of a shift of 4 bits rather than making   
   > it flexible, and rather than simply upgrading to a faster   
   > processor for their alleged speed requirements - so be it,   
   > hardcode the 4.   
   >   
   > > Of course, if you are willing   
   > > to run your programs under Bochs, then performance loss due   
   > > to function call is relatively speaking "small issue".   
   >   
   > On a modern CPU, what happened to real mode programs   
   > was not that they had performance problems, but that   
   > they simply stopped working one day with 64 bit   
   > operating systems, plus they were permanently   
   > constrained to 1 MB. I don't know what the 64 bit   
   > issue was, and I don't really care at the moment.   
   > I'm just interested in why there ever needed to   
   > be a 1 MB limit - the answer is, there didn't.   
   > Never. Microsoft could have coded MSDOS to support   
   > a flexible shift (or even a flexible segment   
   > manipulation) and laid out clear rules. And if Intel   
   > had a vested interest in holding real mode applications   
   > to 1 MB, a competitor could have come along.   
      
   As I wrote, in theory programs should run in protected   
   mode using up to 16 M on 286 and up to 1G on 386   
   (limit on 386 is because two bits in selector encode   
   access rights, so only 14 bits determine actual segment).   
      
   In principle Microsoft could create version of DOS   
   that would run ordinary, but "well behaved" DOS programs in   
   protected mode and allow use of large memory.  I do not know   
   if they did this.  I know that other companies created so called   
   DOS extenders that allowed programs to run in protected   
   mode and use large memory.  As I wrote, program still   
   would run on 8086 in 1M, but programer had to link to   
   extender or use it as a "loader".   
      
   So you should not blame Intel.  Concerning Microsoft, you   
   can blame them because they did not do what you wanted.   
   But in all worlds where your assumptions are true they   
   created such wonder-DOS.  The problem is that such world   
   does not exist...   
      
   > > But most people were in different position. They had 16-bit   
   > > real mode binary programs. They needed to run them. So for   
   > > them it was essential to have VM86 to be able to run existing   
   > > binaries.   
   >   
   > The situation I was in was that I was running   
   > DOS programs in the 1990s, at work, on machines   
   > with something like 16 MiB or 32 MiB of memory,   
   > and I was running out of memory because I was   
   > hitting the 1 MiB barrier.   
   >   
   > It is only recently that I realized it didn't   
   > need to be like that. It was possible to avoid   
   > hardcoding the number 4.   
      
   There is more to this.  There was a lot of programs   
   that hardcoded something like 2M, 4M or similar.   
   They were not affected by 1M barrier and typically   
   would not even run if virtual memory was restricted to 1M.   
   Yes, is was possible to avoid that, but such programs   
   are part of difference between real and fantasy world.   
      
   More generaly, politicians and marketing folk like   
   to talk about "potential" saying that someting has   
   say "huge potential".  In plain language, that means   
   future possiblities, which may materialize or not.   
   But while gains are in future and uncertain, costs   
   are today.  Extra connector for future device, extra   
   bits reserved for some future use have immediate   
   cost.  Your "flexible shift" has its cost too.  You   
   may think that it is worth paying.  In general I like   
   to "future proof" my designs.  But whatever rules I   
   may invent, I have no way to force other folks to   
   follow them.  I have seen folks breaking rules simply   
   because they did not understand why the rule is there.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)