So, something in the make files/build files is skipping building a concrete
GLOBAL for ReturnAnyDosVersionExpected for BC5. There's a MAIN define
checked but the build process doesn't seem to get defined anywhere. :/
Need to do more digging.
On Tue, May 14, 2013 at 9:10 PM, Louis Santillan <lpsan...@gmail.com> wrote:
> BC5 in my hands in 5 days for $35 shipped from Canada.
>
>
> On Thu, May 9, 2013 at 5:58 AM, Louis Santillan <lpsan...@gmail.com>wrote:
>
>> So I bought a shrink wrapped copy of BC5 off ebay today. Should be in my
>> hands in 7-10 days. :D
>>
>>
>> On Tue, May 7, 2013 at 10:45 AM, Louis Santillan <lpsan...@gmail.com>wrote:
>>
>>> On Mon, May 6, 2013 at 5:46 AM, Tom Ehlert <t...@drivesnapshot.de> wrote:
>>>
>>>>
>>>> > Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles.
>>>> Read (
>>>> > ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and
>>>> sections
>>>> > 2.3.x & 3.5. Enlightening and disappointing. There does not seem to
>>>> be a
>>>> > way to get 32-bit instructions out of wcc as Tom had mentioned. 3.5
>>>> > recommends
>>>> Watcom is open source; feel free to add 32 bit instructions to the 16
>>>> bit compiler
>>>>
>>>>
>>> I think recompiling with BC 5.0.2/4.5.2 would be a better option at this
>>> point. I'd love to have the time to do this. :/
>>>
>>>
>>>> > "The recommended options for generating the fastest 16-bit Intel
>>>> code are:
>>>> > Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6
>>>> > Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5
>>>> > 486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3
>>>> > 386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3
>>>> > 286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2
>>>> > 186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87
>>>> > 8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87"
>>>>
>>>> > -ot of -onatx & -zp8 contradict the original makefile's code -os &
>>>> -zp1
>>>> > (optimize execution time vs. executable size & align on byte vs.
>>>> 8-byte,
>>>> > respectively). Also, the -fp*'s opts don't apply and wcc barfs on
>>>> -oi+.
>>>>
>>>> we *want* -os (optimize for size); size matters. both size on disk and
>>>> size in memory are (somewhat) important. speed does *not* matter as
>>>> there is virtually no time spend *inside* the kernel.
>>>>
>>>> to experiment, run some benchmark (like compiling a big project), on
>>>> an optimized kernel vs. not optimized kernel vs. borland kernel.
>>>> measure times. think.
>>>>
>>>> we *need* -zp1 as DOS structures have specific byte offsets.
>>>>
>>>
>>> Thanks for that tip about zp1.
>>>
>>> As for benchmarks (implied by the Regression Tests), that is on the
>>> FreeDOS 1.1->1.2 Road Map Action Items anyways. I'd like to help with that.
>>>
>>> I think I'm going to peruse Simtel and try to find OS benchmarks before
>>> I start writing stuff that simply uses UTILS/RUNTIME. For Regression
>>> Testing, I'd suggest using something like TAP (
>>> http://en.wikipedia.org/wiki/Test_Anything_Protocol). I might even be
>>> able to contribute some code here. Otherwise, we can brainstorm some
>>> benchmarks and tests
>>>
>>> FAT12 vs FAT16 vs FAT32,
>>> File Reads (Small <1K, Medium <1MB, Large <16MB, Huge<2GB),
>>> File Writes
>>> File Creates
>>> File Deletes
>>> RAMDISK vs FDD vs HDD,
>>> File Copies (Same RAMDISK, RAMDISK->HDD, HDD->RAMDISK, RAMDISK->RAMDISK,
>>> Same HDD, HDD->HDD)
>>> With & Without Caching
>>> Cache Sizes
>>> With & Without Share
>>> Process Starts
>>> Boot Times
>>> Kernel Compilation Times
>>>
>>>
>>
>
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
