From: muta...@gmail.com   
      
   On Thursday, September 1, 2022 at 12:15:44 PM UTC+8, muta...@gmail.com wrote:   
   > On Thursday, September 1, 2022 at 10:06:51 AM UTC+8, anti...@m   
   th.uni.wroc.pl wrote:   
   > > muta...@gmail.com  wrote:   
   > > > On Wednesday, August 31, 2022 at 6:44:56 AM UTC+8, Scott Lurndal wrote:   
   > > > > "muta...@gmail.com"  writes:   
   > > > > >On Wednesday, August 31, 2022 at 2:39:56 AM UTC+8, anti   
   ..@math.uni.wroc.pl wrote:   
   > > > >   
   > > > > >However, what about preparation for the future   
   > > > > >by having an instruction that checks the shift value   
   > > > > >in use, and simply returning 4? Or is a   
   > > > > >processor instruction inappropriate?   
   > > > > Note to anti... he's referring to a CPUID instruction analogue.   
   > > > >   
   > > > > Note to muta... Why 4? A single bit is sufficient, and easily   
   > > > > allows future extension to describe additonal optional features.   
   > > >   
   > > > When 8 MB becomes affordable, but   
   > > > the 80386 is still not affordable, the   
   > > > shift will be 6, not 5.   
   > > >   
   > > > This continues up until you have 4 GB of   
   > > > memory. It is highly unlikely we will ever reach   
   > > > 4 GB of memory, I mean, 640 MB should be   
   > > > enough for everyone, but I believe correct   
   > > > mathematical design calls for the   
   > > > theoretical possibility of having 4 GB of   
   > > > memory.   
   > > You clearly leave in alternative universe. In alternative   
   > > universe normal logic, physics or market laws does   
   > > not work, so arguments from real world are invalid.   
   > > Still, it makes sense to say a bit about history.   
   > > > This is the conversation I expect in the Intel   
   > > > design room in 197x.   
   > > Well, if you look at electronics publications you would   
   > > find that already in early seventies it was predicted   
   > > that before 1990 it will be possible to put 360 class   
   > > processor on a single chip. So I expect Intel   
   > > engineers to look at feasiblity of providing 32-bit   
   > > processor. And they did provide one in 1981,   
   > > namely 432. AFAIK in 1982, when 286 was released   
   > > they seriously worked on 386.   
   > >   
   > > Intel folks looked at many ideas, so it is possible   
   > > (evan likely) that idea of variable segment shift was   
   > > considered, but it simply lost to better ideas.   
   > > > I also expect them to conclude that they   
   > > > will make minimal effort for the 8086 itself,   
   > > > but they have a clear pathway for whatever   
   > > > the hell comes after the 8086.   
   > > >   
   > > > I expect the conversation to take an hour or two   
   > > > as they think through the implications for   
   > > > the linker etc to confirm that 4 is not   
   > > > a hard limit, and the software jackasses   
   > > > have all the required tools available if they   
   > > > bother to think it through.   
   > > >   
   > > > And even if they never make actual hardware   
   > > > that can do 5 or more bit shifts, an emulator   
   > > > may be written which can.   
   > > You still do not want to acknowlege that 286 was   
   > > superior design compared to variable segment   
   > > shift. The only drawback of 286 was limitation   
   > > to 16M of memory, but Intel understood that   
   > > with such amount of memory real world users   
   > > want 32-bit processor. So they provided one,   
   > > after failed 432 they deliverd 386. And if they   
   > > failed to deliver, there was 68000 and later   
   > > several RISC processors. Without 386 or similar   
   > > processor PC era would be history now. And 16-bit   
   > > PC era _is_ history.   
   > >   
   > > BTW: Intel got really serious about binary compatibility   
   > > with 386. With 286 "well written" programs are supposed   
   > > to run unchanged in protected mode, but other had to   
   > > be fixed first. With 8086 thay provided tool to translate   
   > > 8080 assembly into 8086 assembly. But instructions encodings   
   > > were quite different, so this did not help if you had only   
   > > 8080 binaries (OK, you had to spend work disassembling   
   > > and then you could use the tool). And that is justified   
   > > by their market: many microprocessors run single program,   
   > > the processor was just one part of a device like printer,   
   > > monitor, disc drive etc. Since thare was single program   
   > > manufactur could spend some effort to adapt it to new   
   > > processor and what Intel provided was adequate.   
   > >   
   > > --   
   > > Waldek Hebisch   
   > I think you misunderstood me. I didn't make any   
   > comment saying variable shifts were superior to   
   > the 80286.   
   >   
   > My only comment was that people writing 8086 software,   
   > including operating systems, shouldn't be hardcoding the number 4,   
   > just because the first processor, just about to be   
   > manufactured, happened to use 4 as the shift value.   
   >   
   > There are multiple ways to avoid hardcoding the number 4,   
   > and one of those ways would be an instruction that returned the number 4   
   > on the 8086, but the 8086 documentation said it is the shift bits,   
   > and not guaranteed to be 4 in future   
   > processors.   
   >   
   > If this had been done, then a future   
   > processor, and indeed it's still not too late,   
   > AMD could do this next year on their x64   
   > processors, in rm16, could suddenly switch to   
   > 5 bit shifts, or anything else up to 16.   
   >   
   > And then all correctly written 8086 software,   
   > including the os, would suddenly have more memory   
   > available.   
   >   
   > What's not to like about that?   
   >   
   > Yes, obviously if you recompile the source,   
   > and the source is clean, allowing 32 bit   
   > everything, that will work too.   
   >   
   > But if all you have is a correct 8086   
   > binary, then that's fine too, most memory   
   > constraints will be lifted thanks to   
   > future development of processors and   
   > cheaper memory.   
   >   
   > And that is the paradigm I want my   
   > 8086 software to adhere to.   
   >   
   > And yes, I'm still developing 8086   
   > apps and an os.   
   >   
   > And yes, I'm hoping AMD will make that change.   
   > Or even Intel.   
   >   
   > Even Bochs would be something.   
   >   
   > If you now understand what I am trying to   
   > do, then I would like specific recommendations   
   > for what should have been done at the time   
   > the 8086 was designed, or failing that,   
   > what should have been done at the time the   
   > 80286 was designed, or failing that,   
   > what change I should make in Bochs rm16   
   > and bios calls.   
   >   
   > Another thing - with the bios being in ROM,   
   > the image will need to have a predefined   
   > segment shift.   
   >   
   > However, if I create my own bootx64.efi,   
   > and install my own int 13 etc to UEFI   
   > code, I think I can have a bios that works   
   > with whatever the segment shift happens to be.   
      
   One more thing I need.   
      
   I want Intel to document that address wraparound at 1 MB is   
   not guaranteed, and implementors should provide a bios   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)