Quote:
Originally Posted by kerravon
I said the *replacement* can be "perfect". I provide a public domain "starter system" and then someone else can use it to implement their definition of "perfect".
|
As a starter system, that's barely a good start. It's an obsolete system. If you want to start something, start from something that follows a good technical design and that builds on state of the art, but not an obsolete system with obvious limitations that requires kludges to work around.
Quote:
Originally Posted by kerravon
I'm interested in C code. I haven't noticed the above causing any problem in any C code I have written, including in PDOS/86 - an operating system.
|
If you're interested in C code, why do you bother about memory models? C doesn't know "memory models". C is build on top of a "virtual machine" with a linear address space. The 8086 memory model is a rather alien ecosystem for C, and that's why these kludges of "near" and "far" pointers exist.
Quote:
Originally Posted by kerravon
Huge pointers are rarely used, but sure, that's the price to pay for trying to access more than 64k for a single object when using 16 bit registers that would normally expect to operate in an environment where the entire application plus OS is expected to fit in 64k.
|
This is the price to pay for an ill-designed system, but again, why do you bother if this is "C only". Why not use a sane system as basis where C can work on top with much less "irregularities".
Quote:
Originally Posted by kerravon
That sounds like a more complicated and expensive design.
|
It is actually a much simpler system. Physical address = segment pointer + offset register. Just that the segment pointer is hidden in a virtual machine, and not accessible legacy applications, and the offset register is all that is seen. It would be the job of the Os to populate the segment pointer in a process-dependent way to allow legacy applications to work. But intel, in their infinite wisdom, created a kludge, something they abandoned in the next generation.
Quote:
Originally Posted by kerravon
If you are using "huge = flat" terminology, sure. No-one disputes flat is easier conceptually. I dispute that it is a problem programmatically. Show me the problematic C code and I'll tell you how to write it properly.
|
The problem is that you have to use two types of pointers "near" and "far", and that C doesn't have such concepts. You cannot just "subtract" two far pointers and get a difference in numbers of objects - the C compiler has to generate code to normalize them, which is inefficient. You cannot subtract near and far pointers as they are of different kind.
Quote:
Originally Posted by kerravon
AMD didn't achieve that at the time the 8086 came out.
|
Apparently not, no, but they didn't come up with "segment pointers" once again - which is the way how intel addressed this issue when "64K is enough for everyone" was no longer acceptable.
Quote:
Originally Posted by kerravon
No, the 8086 and MSDOS 2.0 is going to get 2 years free rein until the Amiga comes out. I just want to prepare for that day.
|
There is nothing to prepare for. The day passed. The days of MS-DOS passed long time ago. The days of AmigaOs passed away. Thus, what's the purpose of this? Prepare for something that is no longer needed? What's the application?
Quote:
Originally Posted by kerravon
I want to advise programmers (who have been tasked by their bosses to program on the XT, and uni courses, how to program for the 8086 in such a way that the source code works on the 68000. Most of the problem is solved simply by backdating C90 and calling it C83.
|
The advice is simple. "Don't". This is obsolete old junk. There is nothing to be demonstrated except that the system was ill-designed. If you want to give someone an advice how to do things, start with the good examples, not the bad ones. You don't program the 8086 today anymore. Neither the 68K - both are museum pieces, interesting parts of technology, one less and one more orthogonal, one less and one more forward looking, but that's about it.
Quote:
Originally Posted by kerravon
Which MSDOS API are you claiming is a kludge that shouldn't be ported?
|
Pretty much all of it. Single-threaded, incomplete interface, not powerful enough for today's applications. It's not how you define an Os interface today. There are reasons M$ left MS-DOS behind with Windows NT, it wasn't simply suitable as foundation of an operating system.
Quote:
Originally Posted by kerravon
All things are possible when you have lots of grunt. The challenge is to deal with low capacity systems. After sorting out the 4.77 MHz XT to my satisfaction I might see what I can do with the 1 MHz Commodore 64.
|
A low-capacity system today is not a 8086 system. Neither a 6502 system. A low-capacity system today is an arm mobile core, as in the raspi, or an arduino core. This is what I would advice as "cheap embedded system" today. Not the obsolete systems of yesterday with their architectural kludges. If your interest "low capacity", that's called "embedded", and 8086 is not quite the answer for this market segment.