Re: [Freedos-kernel] Compilers (the eternal topic :)
Mon, 23 Aug 2004 00:00:30 +1200 (NZST), Bart Oldeman [EMAIL PROTECTED]: 63978 bytes!!! HOORAY!!! ;-) ;-) ;-) Still strange. I get 64266, doesn't matter whether it's OW 1.2 or 1.3. Strange indeed. #if !defined(FORSYS) #pragma aux default parm [ax dx cx] modify [ax dx es fs] #endif in portab.h works only if you use the 386 options that may explain why it didn't work for you. What do you mean by the 386 options? I do use the -3 option as well as -zff -zgf options. The pragma reduces it to 63850 (from 64266, ie. 416 bytes). Wow! I'd like to try this. To reduce compressed size you can try #pragma aux default parm [ax dx] modify [ax bx cx dx es fs] which adds ~200 bytes uncompressed but reduces 300 compressed. Very interesting! Does it also require the 386 options you mention, and what are these options? Also shuffling the link order helps a bit. . ~100 bytes off compressed kernel. Indeed! It helps the Borland kernel too - 86 packed bytes less. -zm gets it further but that's broken (segments messed up), but if that can be fixed you just need to get it below 40960 (80 sectors). That's the threshold I'd like to reach with Watcom in order to replace Borland by it. Anyway the code generator hasn't improved from our point of view. That's the only weak point indeed. They didn't seem to fix the bug I reported (bug 407) either. I suspect there are other bugs introduced in 11.0 but not present in 10.6 that remain in 13.0 (1.3). The compiler is significantly faster for certain code (not sure if that affects FD-kernel). In case you're interested I've put the changes below. Thanks! I read it and saved for my reference. Quite impressive list of changes! I especially like the support of all the instruction sets into the assembler (we use some of them here). Now we have not only the best universal x86 compiler, but also the best MASM-compatible x86 assembler! Shame on Borland who introduced 3DNow! in their inline assmbler but not in their stand-alone TASM! :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Mon, 23 Aug 2004, Luchezar Georgiev wrote: What do you mean by the 386 options? I do use the -3 option as well as -zff -zgf options. Yes that's what I meant. What are the errors dsk.c gives you? That's the only weak point indeed. They didn't seem to fix the bug I reported (bug 407) either. I suspect there are other bugs introduced in 11.0 but not present in 10.6 that remain in 13.0 (1.3). OW is just like FreeDOS here, bugs only gets fixed when somebody is interested enough to fix it, pays someone else to fix it, or hopes that somebody else fixes it, but no guarantees. In your case not enough people have cared about it so far, I'm afraid. A bug tracker just records the bug so it won't be forgotten as easily as writing an email. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, Yes that's what I meant. What are the errors dsk.c gives you? None! :-O Don't know why, but now when I edited the UTILS\MAKEFILE to define EXEFLAT for EXEFLAT.C so that the pragma doesn't affect it, OpenWatcom 1.3 *successfully* built the kernel and the size is... guess what - exactly 63850 bytes, as you wrote! But this is... after adding Eduardo's Int 2F-12 functions! Apack packs that to 42200 bytes. If I pack the exeflatted kernel by it as a .COM file, I get 41967 bytes. UPX gives me 41460 bytes. The other #pragma aux default you suggested gives me 64042 bytes uncompressed, and 41183 bytes compressed by UPX as a .COM file. I suspect I could never reach the sacred size of 40960 bytes :-( For comparison, the aPacked Borland 4.0 kernel is now only 40832 bytes. No, Watcom is just too smart to produce well-compressible code! :) Groet, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Sat, 21 Aug 2004, Luchezar Georgiev wrote: Even after reducing kernel size with my latest patches I still get 65830 bytes. That's more than a kilobyte bigger! How can we explain that? Well I can only try to narrow down by telling exactly what I did: here we go: download UNSTABLE cvs cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/freedos co -rUNSTABLE kernel cd kernel get your patch wget http://linux.tu-varna.acad.bg/~lig/freedos/kernel/CVSPATCH.TXT apply patch -p2 CVSPATCH.TXT resolve rejects in exeflat.c :( Make batch files CRLF as Jeremy converted them find . -name \*.bat | xargs unix2dos copy config.bat from elsewhere, disable UPX Use DOSEMU with OW 1.2 just to make sure. cd to directory build wc 386 fat32 kernel/kernel.sys and kernel/kernel.map have disappeared... Hard to get my fingers used to that. Oh well we still have bin/kernel.sys: 64266 bytes. bin/kernel.map. Also gone... Ok bin/kwc38632.map still exists. I've uploaded it to http://freedos.sf.net/kernel/kwc38632.txt so you can compare the map file. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, resolve rejects in exeflat.c :( Sorry, my fault. Just fixed that and uploaded a new CVSPATCH.TXT, including a SYS fix - OpenWatcom 1.3 now complains about missing return type of fat32readwrite so I addeed an int at both places. I've uploaded it to http://freedos.sf.net/kernel/kwc38632.txt so you can compare the map file. Thanks! Silly me, I had forgotten to rename the FAT and CPU variables to XFAT and XCPU, so what I was getting was a 8086 kernel! Now, with OpenWatcom 1.3, the uncompressed 80386/FAT32 kernel is... 63978 bytes!!! HOORAY!!! ;-) ;-) ;-) Congratulations, Bart! Now we can make some experiments with first exeflatting the kernel, then packing it. But first, please write about your #pragma aux default - why doesn't it work for me? Thank you very much - now I'm looking forward to say Goodbye, Borland! Welcome, Watcom! ;-) Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
63978 bytes!!! HOORAY!!! ;-) ;-) ;-) I'm looking forward to say Goodbye, Borland! Welcome, Watcom! ;-) Sadly, I can't do this yet - UPX compressed it to 41604 bytes as COM and 41614 bytes as EXE. aPack - to 42071 bytes as COM. In contrast, the cowardly Borland 4.0 FAT32/80386 aPacked kernel is just 40718 bytes, almost a kilobyte smaller. So, unfortunately I have to remain a coward :-( Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
UPX compressed it to 41604 bytes as COM and 41614 bytes as EXE. I mean as SYS, not as EXE. I just changed the first 4 bytes to FF to fake it. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hi! 22--2004 12:13 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Thanks! Silly me, I had forgotten to rename the FAT and CPU variables to LG XFAT and XCPU, so what I was getting was a 8086 kernel! Now, with Hm. How you miss kbc8632 instead kbc38632? LG OpenWatcom 1.3, the uncompressed 80386/FAT32 kernel is... OW 1.3? Do you mean, 1.3 is ready?! --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hi! 22--2004 20:29 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO download UNSTABLE cvs BO cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/freedos co BO -rUNSTABLE kernel Hm. Is there consequent tarball of cvs tree? Arkady tree is not very Arkady, so I should sincronize with mine. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hello, I had forgotten to rename the FAT and CPU variables to XFAT and XCPU, so what I was getting was a 8086 kernel! Hm. How you miss kbc8632 instead kbc38632? No, the Borland configuration file was correct, the problem was with my other configuration files! OpenWatcom 1.3, the uncompressed 80386/FAT32 kernel is... OW 1.3? Do you mean, 1.3 is ready?! They had moved the 1.3 from the devel/beta subdirectory onto a new one: http://downloads.openwatcom.org/ftp/zips-1.3/ I think it's a good sign that they're ready to announce it soon. But Bart probably knows more ;-) Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Sun, 22 Aug 2004, Luchezar Georgiev wrote: They had moved the 1.3 from the devel/beta subdirectory onto a new one: http://downloads.openwatcom.org/ftp/zips-1.3/ I think it's a good sign that they're ready to announce it soon. But Bart probably knows more ;-) Michal Necasek just said he was going on holiday for two weeks. He just apparently (didn't know myself) just renamed 1.3rc3 to 1.3 before taking his bags ;) but there hasn't been any formal announcement Anyway the code generator hasn't improved from our point of view. The compiler is significantly faster for certain code (not sure if that affects FD-kernel). In case you're interested I've put the changes below. Bart * The C++ compiler now restricts the scope of variables declared in a for loop to the scope of that loop in accordance with ISO C++, not extending the scope beyond the loop (ARM compliant behaviour). Code relying on the pre-standard behaviour must either be changed or compiled with new -zf switch which reverts to old scoping rules. * Support for default template arguments has been added to the C++ compiler. * Support for alternative tokens (and, xor etc.) has been added to the C++ compiler. It is enabled by default, can be turned off with the new -zat switch. * The C runtime library has been made significantly more C99 compliant. A number of new headers have been added (inttypes.h, stdbool.h, stdint.h, wctype.h) and corresponding new functions implemented. Wide character classification functions were moved out of ctype.h into wctype.h. C99 va_copy macro was added to stdarg.h. * Added 'cname' style C++ headers. * Support for SSE, SSE2, SSE3 and 3DNow! instruction sets has been added. Affected tools are the assembler (wasm), as well as all x86 compilers, disassembler and debugger. The debugger now also supports MMX registers formatted as floats (for 3DNow!) as well as a new XMM register window for SSE. * Inline assembler directives .MMX, .K3D, .XMM, .XMM2 and .XMM3 are now supported in the _asm as well as #pragma aux style inline assembler interface. Note: .MMX directive is now required (in addition to .586) to use MMX instructions. * C compiler performance has been significantly improved (up to 5-10 times speedup) when compiling large and complex source files. * All x86 compilers now have the ability to perform no truncation when converting floating point values to integers. Additionally, 32-bit x86 compilers have the option to inline the rounding code instead of calling __CHP. * The C lexical scanner no longer evaluates constants with (U)LL suffix that fit into 32 bits as zero (1ULL was wrong, LONGLONG_MAX was correct). * C and C++ x86 inline assembler has been fixed to properly process hexadecimal constants postfixed with 'h'. * The C compiler now supports the C99 'inline' keyword, in addition to previously supported '_inline' and '__inline' keywords. * The C compiler now treats a sequence of adjacent character strings as wide if any of the components are wide (required by C99), instead of depending on the type of the last component. For example, Lfoo bar is now interpreted as Lfoo bar, instead of foo bar. * The internal C compiler limit on complex expressions has been increased and if it is still insufficient, the compiler now reports an error instead of crashing. * The C compiler now issues a warning on the default warning level if a function with no prototype is referenced. This was previously warning W301 (level 3), now it is warning W131 (level 1). * Warning W132: No storage class or type specified has been added to the C compiler. This warning is issued if a variable is declared without specifying either storage class or type. This is not allowed in C89. * Warning W304: Return type 'int' assumed for function 'foo' has been added. This warning is issued if a function is declared without specifying return type. This is allowed in C89 but not in C99. * Warning W305: Type 'int' assumed in declaration of 'foo' has been added to the C compiler. This warning is issued if a variable is declared without specifying its type. This is allowed in C89 but not in C99. Note that if warning W132 is issued, W305 applies as well. * The C compiler now properly warns if a function with implied 'int' return type fails to return a value. This potential error was previously undetected. * C++ compiler diagnostic messages have been made more consistent and slightly more detailed. * Linker for Win32 targets can now create file checksums. These are primarily used for DLLs and device drivers, but can be applied to all Win32 PE images if required. * Linker for Win32 targets can now set operating system version requirements into the PECOFF optional header (Microsoft extended header). * Linker for Win32 targets can now set the linker version number into the PE optional header (Microsoft extended header). * The linker will now eliminate zero-sized segments from NE format (16-bit OS/2 and Windows) executables. This fixes a problem where Windows 3.x
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, Well if I claim I can get it under 64K I'm not lying. Did I say you're lying? OW compiles *plain 2035* as 66318 bytes uncompressed for me for FAT32/386. Why your kernel is bigger after all these optimizations is a puzzle. I've read that on low memory machines its optimizer may be limited I have 256 MB RAM and 60 MB free XMS (the rest is for a XMSDSK) - surely enough for it. but I can't think of anything else. What version of OpenWatcom are you using? I use 1.2. I can't otherwise explain the size difference For the unstable branch it's 64700 or so. Even after reducing kernel size with my latest patches I still get 65830 bytes. That's more than a kilobyte bigger! How can we explain that? Changing the calling convention to #pragma aux default parm [ax dx cx] modify [ax dx es fs] in portab.h (careful, don't do that for SYS EXEFLAT) Unfortunately this causes compile errors as early as in dsk.c for me, so I can't use it. and making LoL (init-mod.h, main.c) extern struct lol FAR * const LoL; (see the const) chops of another couple 100s of bytes. Adding const shortens it by 16 bytes for me, so I added it. Borland kernel size doesn't change. The smiley implies that it can't be freely downloaded from Vietnam. Maybe you can but I can't. Why are we so different? I'm much older than you but we both sound like it was the opposite! ;-) Everything can be physically downloaded. ...if you know the right URL at the right time ;-) But that's a silly argument and by publically encouraging it you're not doing this project a favour. Oh, sorry, did I trod the kitten again (as we say here)? I'm scared of myself but not ashamed :) Why? Because I'm a complete copyright illiterate, or at least ignorant. And I'm too old to change. Right, checking again I see it compresses a SYS file like a COM file. Well with some hand holding (load at 50:100) you could treat kernel.sys like a COM file too. Haven't tried that though. Let me first achieve your uncompressed kernel sizes with OpenWatcom. I hope you help me with this. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, Question is how much of a difference can you tolerate? From you I get the impression that a 100K uncompressed kernel that compresses to 3 bytes would be preferable to a 64K one that compresses to 4 bytes. ;-) I could never use an uncompressed kernel that is below 64 KB. OpenWatcom makes the FAT32/80386 unstable kernel 66330 bytes long. The maximum size that UPX accepts is 65350 bytes. The difference is almost a kilobyte. How could we reduce the kernel further without crippling it? It's difficult! I've seen compressed differences between Turbo C++ 1.01 and OW going down over the years. As for Borland, is it worth spending $59+postage for an unsupported product on an obscure Ebay site when so many free compilers are available? It's not worth a penny because it can be freely downloaded from Vietnam (I posted the URL here ;-) How about Digital Mars for instance? A very good compiler in my opinion, backed by Walter Bright's C++ great compiler know-how, but Tom once wrote that he gave up porting the kernel to it as he didn't see advantages. I experimented a bit -- as it turns out once the uncompressed size goes to 64K you can stick on a SYS header to kernel.sys, UPX the already exeflatted SYS file and use that. For some reason in this case UPX is better than APACK by the way. Well I got it down to ~41300 bytes vs. your 40957. Now you're just lucky that 40957 is just below the 80 sector boundary but the difference is gone at 40961 bytes. Does that 64K kernel support FAT32? Hardly. The 40K one at my site does. So that's an incorrect comparison. Besides, aPack doesn't compress .SYS files at all. An incorrect comparison again. Did I say it was bad? I just claim it's not the best tool for our job and has several other disadvantages. You're right, but I have to put up with its disadvantages for one big advantage - KING SIZE! ;-) Do Datalight really use it because the entropy is lower so the compressed size goes down? Their DOS is not compressed at all, although I offered them some stubs to compress a 64K kernel. Of course they lost the race (MSVC, Intel, GCC) when Sybase took over and eventually stopped development. And from what I gather 11.x however introduced various obscure linker bugs, and loop optimization bugs (most are fixed in OW now). And OW still has years to catch up in terms of C++ standards (slowly getting there). The information about loop optimisation bugs is very important. So, not all of them are fixed yet? For example a colleague of mine discovered such a bug which I reported to them. It's present in all Watcoms since 11.0 but wasn't there in 10.6! Unfortunately, there are no bug-free compilers :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Thu, 19 Aug 2004, Luchezar Georgiev wrote: Hallo Bart, Question is how much of a difference can you tolerate? From you I get the impression that a 100K uncompressed kernel that compresses to 3 bytes would be preferable to a 64K one that compresses to 4 bytes. ;-) I could never use an uncompressed kernel that is below 64 KB. OpenWatcom makes the FAT32/80386 unstable kernel 66330 bytes long. The maximum size that UPX accepts is 65350 bytes. The difference is almost a kilobyte. How could we reduce the kernel further without crippling it? It's difficult! Well if I claim I can get it under 64K I'm not lying. OW compiles *plain 2035* as 66318 bytes uncompressed for me for FAT32/386. Why your kernel is bigger after all these optimizations is a puzzle. I've read that on low memory machines its optimizer may be limited but I can't think of anything else. For the unstable branch it's 64700 or so. Changing the calling convention to #pragma aux default parm [ax dx cx] modify [ax dx es fs] in portab.h (careful, don't do that for SYS EXEFLAT) and making LoL (init-mod.h, main.c) extern struct lol FAR * const LoL; (see the const) chops of another couple 100s of bytes. I've seen compressed differences between Turbo C++ 1.01 and OW going down over the years. As for Borland, is it worth spending $59+postage for an unsupported product on an obscure Ebay site when so many free compilers are available? It's not worth a penny because it can be freely downloaded from Vietnam (I posted the URL here ;-) The smiley implies that it can't be freely downloaded from Vietnam. Maybe you can but I can't. Everything can be physically downloaded. But that's a silly argument and by publically encouraging it you're not doing this project a favour. How about Digital Mars for instance? A very good compiler in my opinion, backed by Walter Bright's C++ great compiler know-how, but Tom once wrote that he gave up porting the kernel to it as he didn't see advantages. Sure, Tom's primary interest wasn't compressed kernel sizes at the time, just the uncompressed time (IIRC this was before compressing was even on the radar screen). Does that 64K kernel support FAT32? Of course. Besides, aPack doesn't compress .SYS files at all. An incorrect comparison again. Right, checking again I see it compresses a SYS file like a COM file. Well with some hand holding (load at 50:100) you could treat kernel.sys like a COM file too. Haven't tried that though. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Sun, 15 Aug 2004, Luchezar Georgiev wrote: Besides, you know that Borland C++ 4.0 produces the smallest possible packed kernel binary file. Sometimes kernel file size is what matters (for floppy and ROM disks) and sometimes - the resident size in RAM (where Watcom is the king), if the DOS is in low RAM or if there is no cache. Depends. Question is how much of a difference can you tolerate? From you I get the impression that a 100K uncompressed kernel that compresses to 3 bytes would be preferable to a 64K one that compresses to 4 bytes. I've seen compressed differences between Turbo C++ 1.01 and OW going down over the years. As for Borland, is it worth spending $59+postage for an unsupported product on an obscure Ebay site when so many free compilers are available? How about Digitals Mars for instance? I experimented a bit -- as it turns out once the uncompressed size goes to 64K you can stick on a SYS header to kernel.sys, UPX the already exeflatted SYS file and use that. For some reason in this case UPX is better than APACK by the way. Well I got it down to ~41300 bytes vs. your 40957. Now you're just lucky that 40957 is just below the 80 sector boundary but the difference is gone at 40961 bytes. But on the other hand, Datalight still use Borland as their one and only compiler for ROM-DOS. If it was so bad, would they use it? Did I say it was bad? I just claim it's not the best tool for our job and has several other disadvantages. Do Datalight really use it because the entropy is lower so the compressed size goes down? Bart, some programmers claim that the only true Watcom is 10.6-, and 11.0+ is NO LONGER WATCOM as it was RUINED by Sybase. I have compared the code generated by both, and the difference is not so big, plus the code by 11.0+ is more optimal. What you can say on these Watcom version differences? I don't know. Only ever used 10.x for 32bit a long time ago, and haven't used it at all for several years before openwatcom was there. Of course they lost the race (MSVC, Intel, GCC) when Sybase took over and eventually stopped development. And from what I gather 11.x however introduced various obscure linker bugs, and loop optimization bugs (most are fixed in OW now). And OW still has years to catch up in terms of C++ standards (slowly getting there). Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, We'll make a deal. If Borland fixes their bug in 32RTM as part of open sourcing their old 16bit targetting compiler (even lower than the chance that RBIL will be updated) I'll go for it ;) And this means - never, and you know it! ;-) I do recognize other compilers but... Glad to hear that! ;-) BC isn't a target for freedos optimizations; there's one and only one target to optimize for : WATCOM. so BC specific optimization is a waste of time (ours and yours) True, but my optimisation isn't BC-specific. It's beneficial for all compilers but Watcom! ;-) Besides, you know that Borland C++ 4.0 produces the smallest possible packed kernel binary file. Sometimes kernel file size is what matters (for floppy and ROM disks) and sometimes - the resident size in RAM (where Watcom is the king), if the DOS is in low RAM or if there is no cache. Depends. This is not to say that I like Borland. They added 3DNow! to their inline assembler in C++Builder 6, but NOT in their TASM, which makes me extremely angry at them! But on the other hand, Datalight still use Borland as their one and only compiler for ROM-DOS. If it was so bad, would they use it? This just being tom's opinion but I still agree -- I even agree more than I did a couple months ago, that's why I rejected my own idea of using _seg * pointers. I played for a while again with Turbo C++ back then but in the end decided that the difference was just too big. I agree that this was a right decision. Bart, some programmers claim that the only true Watcom is 10.6-, and 11.0+ is NO LONGER WATCOM as it was RUINED by Sybase. I have compared the code generated by both, and the difference is not so big, plus the code by 11.0+ is more optimal. What you can say on these Watcom version differences? Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
