muta...@gmail.com wrote:
> On Saturday, July 17, 2021 at 6:13:03 AM UTC+10, anti...@math.uni.wroc.pl
wrote:
>
> > Fortunately you answered this question above: you store
> > segment shift in memory. Still, it would be intersting
> > to see machine code that you want for
> >
> > p++;
> >
> > where p is huge pointer (say of type char *). Note:
> > actual instructions, not some handwaving.
>
> Ok, Watcom C generates a call to a function with
> the expectation of particular registers, so ideally
> the code needs to be in assembler, which I'm not
> very good at. I'm better in C.
>
> In addition, in huge memory model, pointers are
> normalized as far as I am aware, so the offset will
> always be less than 16.
>
> 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 know how to handle
normal 4 bit shift, I know to implement what you want.
But that is slow code. I do not know if you can produce
better code or just did not realize how bad is resulting
code.
> I think we're probably in a semantic debate now.
> If you want to call everything a VM, it doesn't affect
> my design. Just a few months ago someone told
> me that PDOS/386 wasn't an operating system, it
> was a file manager and API or something like that.
Well, PDOS/386 is not an operating system, at best is
just part of operating system. But I know that
you really want to call it operating system, so I am
simply ready to translate form your terminolgy to
accepted one.
> > > > In PM16 you do not need prefixes, so this is smallest
> > > > issue. Other are mor significant.
> > >
> > > Ok. But I'm more interested in PM32. Why not take it
> > > to the max?
>
> > You mean why not solve more non-problems? Using PM16 may
> > by too easy, but is was designed for compatibility with
> > real mode, in particular you get 16-bit address size and
> > 16-bit operand size.
>
> I now know that I can avoid the prefixes, in PM32,
> simply by setting the D bit appropriately in all the
> segments. Why would I bother learning how to
> get into PM16?
If you want to do anyting (as opposed to asking other folks
to do coding for you) you need to look up descriptor
format in Intel docs. You will see that each descriptor
has type field. There are several types, but only two
are relevant here: 16-bit code descriptor and 32-bit code
descriptor. If you do far control transfer to descriptor
marked as 32-bit code, then processor switches to 32-bit
mode. If you do far control transfer to descriptor
marked as 16-bit code, then processor switches to 16-bit
mode. If you really know how to get into PM32, you
should also know how to get into PM16. Traditional sequence
to get into PM32 from real mode is as follows:
1) load GDT
2) set PM bit in CR0
3) short jump to flush prefetch queue
4) far jump to code-32 segment
After step 3 processor is in PM16 (short jump is needed to
ensure that following intructions will really work in PM16).
Step 4 is to switch mode to 32-bit.
> Most C programs are full of crap. They won't even
> compile, nevermind run. They will do an unconditional
> #include of the non-existent sys/types.h
Well, switch to better system/compiler which provides
sys/types.h
> > And program were routinely "future-proofed" by izolating
> > tricky/nonoprtable parts in small subroutines. Everybody
> > accepted need to recompile for new machine and rewrites
> > of small non-portable parts. Later in my practice, I
> > learned that unexpected problems played significant role:
> > if probel was expected orignal programmer would work
> > around it, but clearly it did not happen for unecpected
> > problems.
>
> If you're happy to have a 16-bit executable, a 32-bit
> executable, and a 64-bit executable, even for a
> printf("hello, world\n"); then yes, you can solve the
> problem that way.
On my current system support for running 32-bit and 16-bit
executables is not installed, so there are only 64-bit
one. I am happy to recompile if needed. In fact, for
rarely used programs I keep only sources and no binaries,
and compile when needed. And "hello world" is more
often compiled than run.
> But I would also like to have the
> option of coding the hello world as 16-bit, produce
> a single executable, and have it work everywhere.
There are various "solutions" to "work everywhere", but
in modern times "everywhere" does not include 16-bit
systems.
> If anyone has a specific requirement for a 32-bit
> version of the program the onus is on them to
> recompile it.
>
> I was surprised to wake up one day and find that
> my programs in c:\dospath stopped working.
> For decades I had had no reason to recompile them.
> It would have been far better if I had woken up and
> I could suddenly edit 512 MiB files with them. Or
> whatever the application was that just allocated
> memory in chunks as required. Like maybe
> Turbo C++ can suddenly start building 50 MB
> executables.
Dreams are nicer than reality. My modern 16-bit coding
was for machines with small memory, between 512 byte RAM
and 2K RAM (there was also flash, 512 byte RAM machine
also had 16k flash). I am not worried that old 16-bit
programs would not run on those machines and that I need
to recompile.
> > > 2. The 8086 silicon was perfect.
>
> > Here you are making things up. 8086 was a compromise, it
> > worked and won against several competitors. But "won" does
> > not mean it was better then existing competitors, and almost
> > surely it was possible to make better processor.
>
> Not when the requirement is to run 8080 CP/M
> programs in a memory-restricted environment.
Note that 8086 was _not_ binary compatible with 8080.
You had to re-assemble. AFAIK various Z80 based system
offered better compatibility (and they had various kludges
to go beyond 64k).
> > > 3. Intel stuffed up in the documentation by not mentioning
> > > "by the way, assemblers should generate x'66' in front of
> > > a mov ax, bx instruction in order to be future-proofed. If
> > > you omit the x'66', it will still work, but we won't catch that,
> > > and your program will break on the next generation of
> > > processors".
>
> > You miss few important points here:
> > - 8086 code could be run with almost no restriction for 25
> > years after introduction of 8086. With small restrictions
> > it runs up to now.
>
> Not addressing 512 MiB of memory it doesn't.
>
> > - you miss notion of "present value" of future gain. In 1978
> > it was much more important to make sure that 8086 worked
> > well, then worry about future processors. Exactly because
> > of this argument 8086 was reasonable. Otherwise you would
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
