From: muta...@gmail.com   
      
   On Saturday, July 17, 2021 at 6:13:03 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
      
   > Fortunately you answered this question above: you store   
   > segment shift in memory. Still, it would be intersting   
   > to see machine code that you want for   
   >   
   > p++;   
   >   
   > where p is huge pointer (say of type char *). Note:   
   > actual instructions, not some handwaving.   
      
   Ok, Watcom C generates a call to a function with   
   the expectation of particular registers, so ideally   
   the code needs to be in assembler, which I'm not   
   very good at. I'm better in C.   
      
   In addition, in huge memory model, pointers are   
   normalized as far as I am aware, so the offset will   
   always be less than 16.   
      
   Would you like to see some C code that does a p++   
   with the proposed arbitrary segment shifts?   
      
   > Well, one guy creater and "assember" that took S370 assembly   
   > and emited 386 instructions. For this to work he need   
   > "well behaved" programs and IIUC he did not handle endiannes   
   > issue. I would not call his approch "natively executing   
   > S370 binaries in 386". It was clearly a VM created by   
   > instruction translation. For huge mode your apprach is   
   > clearly to related.   
      
   It's not remotely related. All I am doing is making my   
   8086 programs in huge memory model do the 4-bit   
   segment shift using 2 global variables instead of   
   hardcoding the number 4. A more complicated   
   algorithm. With pure 8086 instructions.   
      
   > > That's not a VM. Using a subset of available CPU   
   > > instructions is not a VM. It's neither virtual, nor a   
   > > machine. It's a SUBSET. When you compile a C   
   > > program with perhaps a -mach=486 option when you are   
   > > using a Pentium, it will restrict itself to 486 instructions   
   > > to be generated too. That's not a VM. It's a simple   
   > > application that runs on the 80486 and above.   
      
   > You somewhat did not get that "virtual" means that there   
   > are no real machine. Real 486 exist.   
      
   Almost all VMs are designed to present you with a   
   machine that actually existed. People run VMware   
   or whatever to run an independent x86 processor   
   that really exists.   
      
   > The set of restructions   
   > and capabilities you want for huge model did not exist on   
   > any real machine.   
      
   The capabilities exist. It won't work otherwise.   
      
   The first AMD and first Intel x64 do not actually have   
   identical instruction sets, and when people found out   
   about this they avoided using those incompatible   
   instructions and instead coded to the lowest common   
   denominator.   
      
   So by your definition, almost all code is now being   
   run on VMs.   
      
   I think we're probably in a semantic debate now.   
   If you want to call everything a VM, it doesn't affect   
   my design. Just a few months ago someone told   
   me that PDOS/386 wasn't an operating system, it   
   was a file manager and API or something like that.   
      
   > > > In PM16 you do not need prefixes, so this is smallest   
   > > > issue. Other are mor significant.   
   > >   
   > > Ok. But I'm more interested in PM32. Why not take it   
   > > to the max?   
      
   > You mean why not solve more non-problems? Using PM16 may   
   > by too easy, but is was designed for compatibility with   
   > real mode, in particular you get 16-bit address size and   
   > 16-bit operand size.   
      
   I now know that I can avoid the prefixes, in PM32,   
   simply by setting the D bit appropriately in all the   
   segments. Why would I bother learning how to   
   get into PM16?   
      
   > > > > > Well, it is for you to justify that your apprach will work   
   > > > > > in other modes. Note that to run program as PM16 normally   
   > > > > > you will at least relink it.   
   > > > >   
   > > > > I accept that a relink may be required.   
   > >   
   > > > What about casts betwen data and function pointers? Formally   
   > > > this is undefined in C90,   
   > >   
   > > Yes, for exactly this reason. Works fine today on the   
   > > 8086. Breaks when you move to the 80386 in PM32.   
      
   > Works fine in PM32 as long as you use "tiny" model, that is   
   > no explicit segments, and all segment registers pointing to   
   > the same momory. And in PM32 there are almost no reson to use   
   > segment, as segment operations are just overhead.   
      
   Yes, so it sometimes works, sometimes doesn't.   
   Exactly as C90 said would happen.   
      
   > > > but works in large model. And   
   > > > implementation is just a copy. In PM if you implement this   
   > > > via copy, then program will crash if it tries to access   
   > > > data via such pointer. Such use is probably rare, but in   
   > > > big program rare uses will appear somewhere, so this is   
   > > > restriction on programs that you can run.   
   > >   
   > > gccwin is a 3 MB executable and there is not a single   
   > > such occurrence that I am aware of. The "-ansi -pedantic"   
   > > didn't pick it up, anyway. I don't know beyond that.   
   > > That's 400,000 lines of C code. What's your definition   
   > > of "big"?   
      
   > You look at single rather exceptional program. I ported   
   > quite a lot of programs to DJGPP and there were several   
   > "interesting tidbits". In Scheme interpreter (which I   
   > did _not_ port) there was nice self-modifying routine   
   > to do thing otherwise impossible on 8086.   
      
   Most C programs are full of crap. They won't even   
   compile, nevermind run. They will do an unconditional   
   #include of the non-existent sys/types.h   
      
   I'm not trying to get those programs to run, or even   
   compile. I'm trying to get C90-compliant programs   
   to run.   
      
   > > What would you have done in 1985 if your EMPLOYER   
   > > bought an 8086 and said "please write a program to   
   > > do xyz. And make sure it's future-proofed because I   
   > > hear there's a fantastic new processor coming out   
   > > next year that is going to address 512 MiB of memory   
   > > for 16-bit applications. No more of this 4-bit shift crap.   
   > > Finally Gates and Intel have got it right."   
      
   > You are disconnected with reality. In Intel relased 386 in   
   > 1985. Already when 286 was released in 1982 it was clear   
   > that there will be no 86+. Where I lived "serious" work   
   > in 1985 was done on 370 clones. There were other machines,   
   > if you wanted program running on "most" of them you   
   > coded in Fortran.   
      
   There effectively is an 8086+. It's called an 80386.   
   It's capable of effective 13-bit segment shifts.   
      
   > And program were routinely "future-proofed" by izolating   
   > tricky/nonoprtable parts in small subroutines. Everybody   
   > accepted need to recompile for new machine and rewrites   
   > of small non-portable parts. Later in my practice, I   
   > learned that unexpected problems played significant role:   
   > if probel was expected orignal programmer would work   
   > around it, but clearly it did not happen for unecpected   
   > problems.   
      
   If you're happy to have a 16-bit executable, a 32-bit   
   executable, and a 64-bit executable, even for a   
   printf("hello, world\n"); then yes, you can solve the   
   problem that way. But I would also like to have the   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)