From: muta...@gmail.com   
      
   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...@   
   ath.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.   
      
   > 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.   
      
   Although with patents lasting 20 years, it may not   
   have come along fast enough.   
      
   After nuclear war, 20 year patents may not be a   
   big deal. It's unclear what the situation will be.   
      
   > > You need to challenge my ideas on their merits,   
   > > not resort to argumentum ad populum, which   
   > > has zero effect on me.   
      
   > You do not get it: you say that Intel is monopoly. But they are   
   > commericial company and must look at what customers want. And   
   > in this case they did what majority of customers wanted.   
      
   Sure. Intel doesn't have any obligation to do anything   
   other than obey the law.   
      
   It's not their job to destroy their own monopoly.   
      
   That's where me and the Chicoms come in.   
      
   Or rather, me and the Soviet dictatorship if we're   
   going back to 197x.   
      
   If it's post-nuclear war 2023, I'm not sure who I   
   will try to team up with.   
      
   > 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.   
      
   It still would have required someone to produce   
   a CPU that supported a flexible shift, which   
   wouldn't have been Intel due to their vested   
   interest, but it would have been nice if I knew   
   that the software was all set up correctly, and   
   a monopoly with patent protection was standing in   
   the way. Although if NEC made an 8086/8080 clone,   
   maybe they could have done 5-bit or 8-bit shifts   
   themselves. Who knows.   
      
   I'm only dealing with the software side.   
      
   I want to set the software up to be clean.   
      
   Even if it's only my own software. And I'm now   
   in a position to switch in my own OS, to support   
   the clean apps.   
      
   > When we speak about monopolies: essentially any software provider   
   > is a monoply. If you have say "Silly Editor Mark II" and you   
   > like its key binding and the way it works, than different   
   > editor is _not_ a full replacement. You need _exactly_ the   
   > same behaviour. Replicating behaviour with high accuracy   
   > is large effort, larger than writing software first time.   
   > So normally it is not done and vendor has monopoly. Intel   
   > monopoly is really just consequence of those many software   
   > monopolies and unwillingness of monopolists to support   
   > other platforms. And concerning "forcing", one thing is   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)