muta...@gmail.com wrote:
> On Saturday, July 17, 2021 at 1:21:38 PM UTC+10, anti...@math.uni.wroc.pl
wrote:
>
> > > 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 don't understand this. We may be talking cross-purposes.
> Assembler generated ... from what? A C90 program
> compiled in huge memory model using Watcom C?
Assembler that _you_ want. What Watcom C generates will
not work (in way that you want).
> That generated C doesn't change one iota.
>
> Nor does the code generated from any other memory
> model.
Without change to generated code your "arbitrary shift"
huge model will not work. For other model changes to
linker and loader are enough, but not for huge model.
> > > 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.
>
> Wow. Ok, the last person who made that claim didn't
> actually answer me when I asked him what definition
> of "operating system" he was using. So maybe you
> can answer.
"operating system" is a somewhat fuzzy notion. In
narrow sense it means kernel, that is software responsible
for driving hardware and providing more abstract view
of the machine. In wide sense beside kernel it includes
various utilities, libraries etc.
> 1. Was MSDOS an operating system, and if so, why?
MSDOS + BIOS was an operating system. MSDOS alone not.
Note that "MSDOS" was available for early PC clones
witout IBM BIOS, "available" included replacement for
BIOS.
> 2. Why is PDOS/386 not an operating system?
1) To get system in narrow sense above you need BIOS,
so that is why I wrote "part". Do you have any
drivers for devices not supported by BIOS?
MSDOS could support devices via non-BIOS drivers,
most were third-party, but IIUC some were bundled.
2) In wider sense, AFAICS there are almost no utilites
in PDOS.
> > > 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)
>
> What are you talking about? I've been working on
> PDOS for 27 years. This is not a future tense
> situation.
This whole discussion is about things not support in your
current PDOS, so about future work.
> > you need to look up descriptor
> > format in Intel docs. You will see that each descriptor
>
> I already consulted that something like 24 years ago.
> The knowledge is now encapsulated in public domain
> code, and I no longer have any interest in it except
> just now when I started thinking about PDOS/86
> again.
If you have no interest, then why this discussion? For
what was disscussed descriptor format is crucial.
> > 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.
>
> It's more "knew" than "know". And I only focused on
> getting into PM32, not stopping to think whether I
> had just passed PM16 and whether that would be
> useful for anything. I wanted a flat 32-bit address
> space as priority. I had very little interest in 16-bit
> coding until just recently.
>
> > > 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
>
> No, I will switch to better applications, that don't
> include sys/types.h and actually follow the C90
> rules.
>
> I'm not expecting you to follow my route. But don't
> expect me to follow yours either.
>
> > 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.
>
> Again, you are free to do whatever you like. Me, I want
> my 16-bit programs to be clean, meaning no hardcoding
> of the number 4.
>
> I also want my S/3X0 programs to be clean, ie no
> messing with the top address bit, so that they can
> run as AM32.
>
> > > 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.
>
> Not everyone shares that opinion, even in modern
> times. I cater for people who like the idea of clean
> 16-bit 8086 programs running on both an 8086
> and addressing 512 MiB on an 80386.
>
> > > 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.
>
> That's fine. I don't care if you're not worried. I care, and
> I'm interested in a technical discussion. I'm not trying
> to get you to buy current PDOS/86 or future PDOS/86.
>
> > > > > 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
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
