[Freedos-kernel] Potential issues with FAR printf
Jeremy: The FAR printf is probably good for 16-bit builds with DEBUG defined. However, there are at least two potential issues (NOT YET VERIFIED). 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past 4GB. I don't know how the compilers treat FAR in these builds. 2.Low memory systems? It might be good (though perhaps difficult) to 1 Check for 16-bit 2 Check for DEBUG If both are true, 3 Use FAR printf Thank you, Ibidem -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Potential issues with FAR printf
2009/7/20 ibid...@lavabit.com: Jeremy: The FAR printf is probably good for 16-bit builds with DEBUG defined. However, there are at least two potential issues (NOT YET VERIFIED). 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past 4GB. I don't know how the compilers treat FAR in these builds. 2.Low memory systems? It might be good (though perhaps difficult) to 1 Check for 16-bit 2 Check for DEBUG If both are true, 3 Use FAR printf with my commit printf only now uses FAR pointers for DEBUG statements in resident code, but just to clarify: the 386 builds don't use 32-bit code segments with 32/48-bit pointers, DPMI, etc, they only tell the compiler that it is allowed to use CPU instructions that are only available on 386+ processors, such as movsx, movzx, and those involving fs and gs segments. Some compilers use 32-bit registers for (unsigned) longs. But It all remains real mode code with 16-bit segments. The *only real* advantage of the 386 builds is that the code size decreases so kernel.sys and its resident memory footprint decrease; theoretically it could be a bit faster too but I'd be surprised if anyone could measure that. Bart -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Potential issues with FAR printf
The FAR printf is probably good for 16-bit builds with DEBUG defined. However, there are at least two potential issues (NOT YET VERIFIED). 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past 4GB. I don't know how the compilers treat FAR in these builds. exactly as the 16 bit builds. this is REAL mode. Tom -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
