From: muta...@gmail.com
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, 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.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
