From: muta...@gmail.com   
      
   On Monday, July 19, 2021 at 5:01:37 AM UTC+10, anti...@math.uni.wroc.pl wrote:   
      
   > > > > Would you like to see some C code that does a p++   
   > > > > with the proposed arbitrary segment shifts?   
   > >   
   > > > No, I would like to see _assembler_ generated with support   
   > > > for arbitrary segment shifts.   
   > >   
   > > I don't understand this. We may be talking cross-purposes.   
   > > Assembler generated ... from what? A C90 program   
   > > compiled in huge memory model using Watcom C?   
   >   
   > Assembler that _you_ want. What Watcom C generates will   
   > not work (in way that you want).   
      
   Yes it does. It calls an external routine to adjust the   
   pointer.   
      
   C:\devel\pdos\pdpclib\xxx8>type foo.c   
   int foo(char *p, unsigned long x)   
   {   
       p += x;   
       return (*p);   
   }   
      
   wcl -q -w -c -I. -mh -zl -D__MSDOS__ -fpi87 -s -zdp -zu -ecc foo.c   
      
   (note the -mh)   
      
   C:\devel\pdos\pdpclib\xxx8>wdis foo.obj   
   Module: C:\devel\pdos\pdpclib\xxx8\foo.c   
   GROUP: 'DGROUP' CONST,CONST2,_DATA   
      
   Segment: foo_TEXT BYTE USE16 00000020 bytes   
   0000                          _foo:   
   0000    55                        push        bp   
   0001    89 E5                     mov         bp,sp   
   0003    C4 5E 06                  les         bx,dword ptr 0x6[bp]   
   0006    8B 4E 0C                  mov         cx,word ptr 0xc[bp]   
   0009    89 D8                     mov         ax,bx   
   000B    8C C2                     mov         dx,es   
   000D    8B 5E 0A                  mov         bx,word ptr 0xa[bp]   
   0010    9A 00 00 00 00            call        __PIA   
   0015    89 C3                     mov         bx,ax   
   0017    8E C2                     mov         es,dx   
   0019    26 8A 07                  mov         al,byte ptr es:[bx]   
   001C    30 E4                     xor         ah,ah   
   001E    5D                        pop         bp   
   001F    CB                        retf   
      
   I just need to write __PIA.   
      
   Since it is nominally meant to be written in assembler,   
   that isn't very easy for me. But I could simply write a   
   small amount of assembler to push those registers   
   onto the stack and return to C, which I am comfortable   
   with.   
      
   > > That generated C doesn't change one iota.   
   > >   
   > > Nor does the code generated from any other memory   
   > > model.   
   >   
   > Without change to generated code your "arbitrary shift"   
   > huge model will not work. For other model changes to   
   > linker and loader are enough, but not for huge model.   
      
   Please let me know if the above isn't sufficient.   
      
   > "operating system" is a somewhat fuzzy notion. In   
   > narrow sense it means kernel, that is software responsible   
   > for driving hardware and providing more abstract view   
   > of the machine. In wide sense beside kernel it includes   
   > various utilities, libraries etc.   
      
   Ok, if you're throwing in even utilities, then yes, PDOS/386   
   is not an operating system.   
      
   > 1) To get system in narrow sense above you need BIOS,   
   > so that is why I wrote "part". Do you have any   
   > drivers for devices not supported by BIOS?   
      
   Someone added a VGA driver because they didn't   
   like it going to the BIOS to do that. It took me a   
   while to figure out why my Bochs debug output   
   via E9 hack wasn't working, and I traced it back   
   to this, so deactivated it by default, so back to the   
   BIOS.   
      
   Other than that, no, nothing at all.   
      
   > > > you need to look up descriptor   
   > > > format in Intel docs. You will see that each descriptor   
   > >   
   > > I already consulted that something like 24 years ago.   
   > > The knowledge is now encapsulated in public domain   
   > > code, and I no longer have any interest in it except   
   > > just now when I started thinking about PDOS/86   
   > > again.   
   >   
   > If you have no interest, then why this discussion? For   
   > what was disscussed descriptor format is crucial.   
      
   As I said above, just recently I became interested again.   
      
   > > > > That sounds like a flat 32-bit model implemented on 16-bit   
   > > > > hardware. That's the equivalent of segmentation with a   
   > > > > 16-bit shift. Which defeats the purpose of 4-bit shifts.   
   > > > > Intel didn't use the number 4 instead of the number 16   
   > > > > for fun.   
   > >   
   > > > There was no segmentation, 360/20 was limited to 64k memory   
   > > > (max that true 16-bit machine could handle).   
   > >   
   > > A 32-bit register with the top 16 bits always 0 is the   
   > > equivalent of a segment register set to 0.   
   >   
   > You could say that no segment register is equivalent to   
   > segment register set to 0. But if there are no actual   
   > segment register, then pretending that there is one   
   > bring nothing but confusion.   
      
   If you have allocated 16-bits for the high bit of an   
   address, and at the moment it always needs to be   
   set to 0, then if you write your code appropriately,   
   it can be considered a segment register, and will   
   indeed work on a segmented system.   
      
   If you write your code assuming that the defacto   
   segment register will always be shifted 16 bits, then   
   it is a flat pointer.   
      
   > > > You needed   
   > > > better model to get more memory. AFAIK all other models   
   > > > had 32-bit registers (but there were rather severe restrictions   
   > > > on max supported memory). But if you think that 32-bit   
   > > > registers are too expensive and memory is cheap enough to   
   > > > have more of it you could create fictional 360/27 having   
   > > > say 2 or 3 register extended to 20 bits.   
   > >   
   > > That exceeds the 16-bit registers. That's not achieving   
   > > what the 8086 achieved.   
   >   
   > That is better thing: transparent compatibility to bigger   
   > machines that seem to be so dear to you. Note that   
   > beyond tiny model, what 8086 does exceeds the 16-bit registers:   
   > you need 32 bit addresses (segment + offset) and pair   
   > of register emulating bigger one. Explicit logically 32-bit,   
   > physicaly 20-bit register is cleaner.   
      
   It may be cleaner/easier, but it defeats the purpose for   
   what segmentation was created for. Intel didn't come   
   up with a segmented processor for fun, and they didn't   
   use a 4-bit shift because they'd been smoking wacky   
   weed. It was the absolute correct engineering solution.   
      
   > > > You could then   
   > > > use those registers to access 1M, with binary compatibility   
   > > > with bigger machines. And with hidsight, you could correct   
   > > > 24-bit limitation.   
   > >   
   > > There is no 24-bit limitation. That is down to individual   
   > > programmers choosing to pollute unused bits. If you   
   > > write your S/370 programs properly, they work fine,   
   > > at an unchanged binary level, on a AM32 processor like   
   > > the S/380.   
   >   
   > BAL and BALR pollute high bits.   
      
   Those only pollute the high 8 bits in AM24, where it   
   doesn't matter.   
      
   In AM31 they only pollute the top bit, where it doesn't   
   matter.   
      
   In AM32 and AM64, they do not pollute any high bits.   
      
   > LA replaces high bits by zero.   
      
   In AM31 it only clears the top bit.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)