OSDev.org

rdos wrote: In essence, both Windows and Linux use 64-bit as if it was 32-bit, and thereby destroying any advantage of 64-bit mode.

Destroying one advantage maybe, but surely not any advantage.

Combuster wrote:

rdos wrote:because the compiler cannot handle putting some part of the code at 128G, another part at 256G.

-mcmodel=large says you're a liar.

It would if it had worked, but it doesn't. I have already sent one patch for this to GCC, but there are other things that still doesn't work. For instance, weak links doesn't work and results in linker errors.

Hi,

bwat wrote:

Brendan wrote: Compilers tend to be designed for OSs.

Compilers are designed for languages (as were architectures, the old saying was "language first, architecture second", but now that's different).

Most modern compilers aren't designed for one language - they're designed for multiple different "front-ends" that support many different languages and generate the same intermediate language; and also have multiple "back-ends" to support multiple architectures (typically whatever architectures the OS they're designed for support - e.g. 80x86, ARM, .NET and nothing else for VisualStudio, because that's all the architectures that Windows supports).

bwat wrote:Did you mean "Compilers tend to be designed for architectures" instead? That I could agree with in this day and age.

No. More accurately, I meant toolchains are designed for OSs (not just the compiler, but standard libraries, assembler, linker, etc). You might be able to force a tool-chain designed for Windows to generate ELF object files with third-party tools and cobble together some way of generating *nix applications; and you might be able to port an open source compiler designed for *nix to a different platform; but this is rarely the primary goal of the tool-chain.

It's not just compilers though. Almost all good applications (including compilers, text editors, games, word processors, etc) are initially designed to suit a specific OS (and then maybe if you're lucky someone will add a "bloat layer" or spend ages porting it to a different OS where it just isn't as good). Sadly, there are a lot of "boring old POSIX" OSs that are mostly the same regurgitated 1960 *nix thing, where the differences between these "different" OSs are so minor that it's hard to tell which variation any application was actually originally intended for (e.g. GNU/Linux vs. GNU/Solaris vs. GNU/freeBSD vs. GNU/yawn_shoot_me_now); so it might be hard to tell now.


Cheers,

Brendan

Hi,

rdos wrote:It is quite clear that both Windows and Linux either put their kernel image at the top 2G or the bottom 2G, because the compiler cannot handle putting some part of the code at 128G, another part at 256G. If either of those platforms used other positions for code, they would have fixed these bugs long ago. In essence, both Windows and Linux use 64-bit as if it was 32-bit, and thereby destroying any advantage of 64-bit mode.

I think you're doing the equivalent of "Wet clothes cause rain" when it's actually the opposite ("rain causes wet clothes").

It's a lot more likely that the reverse happened. AMD made using 32-bit addresses more efficient, so both Linux and Windows tried to improve performance by using the more efficient 32-bit addresses where possible, which led to using the lowest and highest 2 GiB of the address space for code (e.g. 32-bit addresses sign extended to 64-bit to avoid wasting space for 64-bit addresses/immediates). Of course when OSs are mostly using the lowest and highest 2 GiB of the address space for code it makes sense for a compiler to support what the OS mostly uses before worrying about things that aren't as important (like "-mcmodel=large" and support for applications with more than 4 GiB of code; and OSs where code is splattered all over the address space like it got shot out of a donkey with a severe case of explosive diarrhea).


Cheers,

Brendan

Brendan wrote:Almost all good applications (including compilers, text editors, games, word processors, etc) are initially designed to suit a specific OS

I would say any good software defined supported OS, but it might be more than one.

Furthermore, supporting multiple OS might not add extra bloat, you can have some kind of cross-platform interfaces that warp to native API.
or if it does add some bloat, it should not affect perspective performance (otherwise it is not good software).

Brendan wrote:

bwat wrote:Did you mean "Compilers tend to be designed for architectures" instead? That I could agree with in this day and age.

No. More accurately, I meant toolchains are designed for OSs (not just the compiler, but standard libraries, assembler, linker, etc).

If this were true, the difference between the GCC toolchain for Solaris on x86 and GCC for Linux on x86, would be greater than the difference between GCC for Solaris on X86 and GCC for Solaris on SPARC. I'm not sure that is the case. I've personally never built a compiler, either professionally or as an amateur, that has been designed for an OS; the target architecture has always influenced design more. This is also reflected in pretty much every compiler textbook I've read - I've never seen a section on OS specific design.

rdos wrote:Your knowledge is outdated.

Then the OpenWatcom wiki is outdated.

OpenWatcom supports 32-bit code generation, and it is one of few compilers that can produce 32-bit segmented code for OS/2. So your claims that OpenWatcom is a 16-bit compiler only for legacy is false.

I never claimed that it does not support 32 bit. I claimed only that it does not appear to support 64 bit. It is therefore legacy.

Given that OpenWatcom could be ported to RDOS, and also could be adapted to generating 32-bit segmented device-driver code clearly also supports that it can be ported to new segmented platforms.

Who would waste their time writing a new segmented OS?

If I was to start on OS-development from scratch today, I'd make sure I had a dual-platform code-base which could be run both segmented (with paging) and flat. That's a recipe for success. Flat memory models in a monolithic kernel is a recipe for disaster.

Ah, ok....

Brendan wrote:Hi,

rdos wrote:It is quite clear that both Windows and Linux either put their kernel image at the top 2G or the bottom 2G, because the compiler cannot handle putting some part of the code at 128G, another part at 256G. If either of those platforms used other positions for code, they would have fixed these bugs long ago. In essence, both Windows and Linux use 64-bit as if it was 32-bit, and thereby destroying any advantage of 64-bit mode.

I think you're doing the equivalent of "Wet clothes cause rain" when it's actually the opposite ("rain causes wet clothes").

It's a lot more likely that the reverse happened. AMD made using 32-bit addresses more efficient, so both Linux and Windows tried to improve performance by using the more efficient 32-bit addresses where possible, which led to using the lowest and highest 2 GiB of the address space for code (e.g. 32-bit addresses sign extended to 64-bit to avoid wasting space for 64-bit addresses/immediates). Of course when OSs are mostly using the lowest and highest 2 GiB of the address space for code it makes sense for a compiler to support what the OS mostly uses before worrying about things that aren't as important (like "-mcmodel=large" and support for applications with more than 4 GiB of code; and OSs where code is splattered all over the address space like it got shot out of a donkey with a severe case of explosive diarrhea).


Cheers,

Brendan

So you agree they just made a horrible 32-bit kernel and called it a 64-bit?

Hi,

rdos wrote:

Brendan wrote:

rdos wrote:It is quite clear that both Windows and Linux either put their kernel image at the top 2G or the bottom 2G, because the compiler cannot handle putting some part of the code at 128G, another part at 256G. If either of those platforms used other positions for code, they would have fixed these bugs long ago. In essence, both Windows and Linux use 64-bit as if it was 32-bit, and thereby destroying any advantage of 64-bit mode.

I think you're doing the equivalent of "Wet clothes cause rain" when it's actually the opposite ("rain causes wet clothes").

It's a lot more likely that the reverse happened. AMD made using 32-bit addresses more efficient, so both Linux and Windows tried to improve performance by using the more efficient 32-bit addresses where possible, which led to using the lowest and highest 2 GiB of the address space for code (e.g. 32-bit addresses sign extended to 64-bit to avoid wasting space for 64-bit addresses/immediates). Of course when OSs are mostly using the lowest and highest 2 GiB of the address space for code it makes sense for a compiler to support what the OS mostly uses before worrying about things that aren't as important (like "-mcmodel=large" and support for applications with more than 4 GiB of code; and OSs where code is splattered all over the address space like it got shot out of a donkey with a severe case of explosive diarrhea).

So you agree they just made a horrible 32-bit kernel and called it a 64-bit?

Of course not - I'm saying that they designed their 64-bit kernels to be efficient; and that you're complaining about the way their tools evolved to support their more efficient design simply because your code is less efficient.

If you don't like the way GCC evolved, then maybe you should just use OpenWatcom to generate nice segmented 64-bit code for you.

Note: This technique is actually very old. I still remember 6502, where there was a special area called "zero page" that was more efficient as you could use 8-bit addresses to access it instead of the normal 16-bit addresses, where people carefully selected the most important pieces of data to squeeze into that little 256-byte area.


Cheers,

Brendan

Brendan wrote: Of course not - I'm saying that they designed their 64-bit kernels to be efficient; and that you're complaining about the way their tools evolved to support their more efficient design simply because your code is less efficient.

Efficient code that is full of bugs is of no interest.

Brendan wrote: If you don't like the way GCC evolved, then maybe you should just use OpenWatcom to generate nice segmented 64-bit code for you.

Used in the right way, long mode could offer the same level of protection as segmentation, because the extra 16 bits of addresses (which are not reachable through 32-bit offsets) are equal to the 16 bits of segments, making invalid pointers fault to a high degree. Used in the wrong way (lower or higher kernels), they are just as bad as their 32-bit flat counterparts.

> because the extra 16 bits of addresses are equal to the 16 bits of segments
Rdos finally found the way to use his beloved segmented model in long mode. Amazing skill of searching similarities and difficulties. Thunderous applause.

Ok, this idea is really interesting but here are two problems:
1) it doesn't seem much better than just a one guard page after (and possibly before) each allocated region;
2) the only thing that I like in segmentation is an ability to set limit that isn't a multiply of a page size to catch array overflows w/o perversions like aligning arrays to the end of page. Your idea doesn't help in catching such corner cases.