From: muta...@gmail.com   
      
   On Thursday, September 1, 2022 at 8:42:31 PM UTC+8, muta...@gmail.com wrote:   
   > 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...   
   math.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, an   
   i...@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,   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)