Hi, On Fri, Dec 1, 2017 at 11:00 AM, Bart Oldeman via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote: > > On 22 November 2017 at 09:57, Tom Ehlert <t...@drivesnapshot.de> wrote: >> as a side note: if gcc has no far pointers, its usability as a 16 bit >> compiler is serious limited. > > There is one now, finally, since T.K. Chia started working on the IA16 > port in June. > https://github.com/tkchia/gcc-ia16/
So they only patched it this year? That makes more sense (since GCC IA16's initial public release seems to have been in April). > I managed to compile the FD kernel with it even with the crazy memory > model. Some magic was involved. > Results aren't stellar (the size is similar to Turbo C, i.e. ~80k > uncompressed for 86 + FAT32; OW is closer to 70k), but I have been > pestering the developer with bug reports and the compiler steadily > improves. Very interesting. (But what is the problem with 80kb? Slightly less free memory? Not exactly a deal-breaker!) > Alternatively said: ia16-elf-gcc and binutils does not support OMF, > only ELF, and therefore NO segment relocations, as ELF is flat. You mean even ELF (with 8-bit extensions) isn't fully supporting all features? Jenner did indicate plans to maybe add OMF eventually, but that sounds like it would be onerous. Don't hold your breath. > The kernel needs to compute the value of DosDataSeg at runtime and store > it somewhere. > A linker script can still create a kernel.exe with 0 relocations and a > 32-byte custom header. There was a linker bug in Jenner's April release, but he has since fixed / upgraded to avoid that. > Also the compiler only understands cdecl and no pascal calling > convention, so that meant quite a few changes to the asm interfaces -- > simple work reverting the argument order and using ret instead of ret > n. Kernel 2042 is apparently using 27 .ASM files! Most are fairly small, though. FYI, NASM is still cross-compiled via DJGPP for DOS with official binaries (e.g. 2.13.01). But I'm not sure it can build natively (well, unless you "configure" elsewhere.) I think OpenWatcom support has been dropped entirely since (I don't know) 2.10? (But I can build 2.09.10 via OW in DOS with no obvious problems.) But latest release is close to almost compiling with OW again (and I think Joe Forster's fork is using it). There were some old comments about only using 16-bit NASM for kernel compilation, but that's not necessary (IIRC, if using wmaker instead of pmode wmake). So we're not forcibly stuck to oldy-moldy 0.98.39 (not that we truly need much newer). EDIT: Oops, just noticed that 2.13.02 was released a few days ago. It seems to have added OpenWatcom dependency info in OMF/OBJ (plus option -MW). Not sure if that makes a difference for you. > I'll submit the changes once the other compilers can compile it again :) Okay, sounds good. > I find it rather striking that after 17 years that Linux distributions > have not been able to distribute FreeDOS and DOSEMU as free software > in there base distributions because of a dependency on > not-completely-free compilers somebody finally implemented far > pointers in GCC. I don't know what DOSEMU2 did about it, if anything. I've never bothered trying to recompile DOSEMU (and wouldn't know what to do there anyways). But yes, it's pathetic that it was so heavily shunned. Obviously most Linux distros make many exceptions for "important" things (like firmware, microcode, multimedia codecs, etc), but I guess DOSEMU wasn't considered essential enough. Well, even VirtualBox (BIOS) has the same "problem" nowadays. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
