> Alan kindly explained to me in the last few days in the thread > http://www.spinics.net/lists/linux-8086/msg00813.html what kind of > complex things ELKS would need to do to handle processes with multiple > code segments and/or multiple data segments, and those restrictions > are still there, so simply using GCC doesn't make them go away. > There are two problems: the userspace, where the above holds, and the kernel space, where there are multiple data segments (without any explicit compiler support). The advantages of GCC are: a modern compiler, better inline assembly, better code, etc. > - Section 3.2 says "Although this version of Sourcery CodeBench Lite > uses ELF as its internal object format, it produces executables in DOS > COM format." DOS .COM format implies a single 64KB segment for > combined code and data, i.e. tiny memory model, right? That's more > restrictive than ELKS. > This is more a limitation of the linker than of GCC. And workarounds can be implemented. > - Section 3.3 says "Far pointers currently do not work, so accessing > memory outside the program's 64kB segment requires the use of assembly > (either inline or a separate file that is assembled and then linked > into the program).", so it's not going to let you make bigger > executables even if ELKS added such support. For what it's worth > you'd find far pointer support in OpenWatcom. > Switching to another compiler would require rewriting large portions of the current code base. So it is an important decision. What is important for developers is that the compiler handle modern standards, decent inline assembly, currently supported, etc. And there are the requirements for the compiler to be open source with an acceptable license. Someone at this list mentioned in the past an objection to the license of OpenWatcom. Assuming that OpenWatcom fulfills the developer's requirements, what is needed is a the complete certainty that its licence is acceptable. > I see that ia16-elf/lib/dos-com.ld seems to have some instructions > related to making a DOS .COM file. I've never played with GCC linker > scripts before, but I assume there's nothing in the compiler that > would prevent it from generating a full 64KB code segment and also a > full 64KB data segment, and one could make a linker script for > generating an ELKS executable with those two separate segments instead > of being limited to it all being in one segment like with a .COM file? > I agree. As I said, this is more a problem with the linker. Indeed, the object files produced by GCC can be made to have separate code and data. -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
