From: muta...@gmail.com   
      
   On Tuesday, July 20, 2021 at 11:31:52 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
      
   > > 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.   
      
   > OK, with appropriate __PIA it will work. But this is   
   > really bad (slow) code...   
      
   Which is why you only use huge memory model if   
   absolutely necessary, and you're prepared to wear   
   the cost.   
      
   I have one single application where I consider it to   
   be "necessary" and it is not performance-critical so   
   I don't care what the overhead is. Like I said - even   
   if the PIA calls (with or without two flexible OS-provided   
   shifts) make the entire application 3 times   
   slower, I don't care. I doubt that in reality the difference   
   will even be detectable by a human observer on an   
   8086.   
      
   I do care that it can address 512 MiB though. Or 1 MiB   
   for that matter.   
      
   > > > > 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 ignore crucial part: if you want to access character   
   > array starting at 50000 using index 30000 you end up   
   > with address 80000. Of course, with 16-bit address it   
   > will not work. But if you expand memory and add extra   
   > bits to address registers it will work fine. In segmented   
   > model there are _no_ carry from offset part to segment   
   > part and access will not work.   
      
   Ok, good point.   
      
   But we're still left with the fact that this is addressing   
   a different problem to the one the 8086 addressed.   
      
   > Of course, you can try to cover up hardware deficiences   
   > in software, but handling carry at hardware is resonably   
   > cheap, emulating the same thing in sofware is problematic   
   > (slow and large code).   
      
   Sure. Using non-tiny-memory model is a tradeoff that   
   needs to be made. If you can ever use tiny memory   
   model - use it. It's the only thing that is going to work   
   for that instruction set on a CPU that has no segment   
   registers and only 64k of memory.   
      
   > > > > > 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.   
      
   > I wander what in your opinion was purpose of segmentation?   
      
   To allow multiple tiny-mode applications to run, without   
   requiring alignment on a 64k address boundary, thus   
   wasting space.   
      
   > 4-bit shift was actually kind of reasonable, certainly better   
   > than 16 (or 13) bit shift that you advocate.   
      
   I advocate 4-bit shift on the 8086, and 16-bit shift if you   
   have a machine capable of addressing 4 GiB and that   
   amount of memory actually installed, and an effective   
   13-bit shift on the 80386 where design limitations limit   
   you to 512 MiB.   
      
   As opposed to what alternative for large memory model   
   8086 programs? There's some advantage to restricting   
   them to 1 MiB instead of letting them fly on an 80386?   
      
   > 8086 was "correct" in sense that it was good enough to make   
   > a lot of money for Intel (unlike failures like 432 or   
   > Itanium). But they could make better processor.   
      
   IBM selected it for a reason too. IBM wasn't on wacky   
   weed either. It was the right processor for what IBM   
   had in mind - CPM-compatibility.   
      
   Maybe you should say that IBM should have had a fresh   
   start instead. Which is more-or-less what they did with   
   OS/2.   
      
   Maybe they got it wrong both times, I don't know.   
      
   If someone has their heart set on running CP/M programs,   
   that presents a technical challenge, and Intel and IBM made   
   the exact correct technical choice.   
      
   > > > > > 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 AM24 high bit contain information, not present in AM31.   
   > Due to trash in high bits, if you need to compare addresses,   
   > you need to mask high bits, if you mask, you will fail   
   > in AM31.   
      
   The masking process is "LA" and it will clear the top 8   
   bits in AM24 and the top 1 bit in AM31.   
      
   This is all perfectly correct. It's the same instruction.   
   If you code correctly, it works in all environments.   
      
   > > 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.   
      
   > Yes, and this is different than in AM24. LA is   
   > useful as arithmetic instruction with 12-bit   
   > immediate. IIRC alternatives are much more   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)