paul@cacilj.UUCP (Paul Close) (01/19/89)
I was happy to see that the NULLFILL recently posted actually clears the BSS.
My question is, if the clearing routine is so fast, why not just clear
everything and make ALL programs happy? After all, what's a few milliseconds
among friends?
I'm not familiar with the source code--could someone give me pointers on how
to clear the heap and stack, etc. like TOS does? (except using the fast
nullfill routine, of course.)
Thanks,
--
Paul Close paul@cacilj.CTS.COM ...!{uunet, ucsd, crash}!cacilj!paul
The Obi-wan Kenobi method: "Use the Source, Luke" -Jim Fultonleo@philmds.UUCP (Leo de Wit) (01/22/89)
In article <873@cacilj.UUCP> paul@cacilj.UUCP (Paul Close) writes: |I was happy to see that the NULLFILL recently posted actually clears the BSS. |My question is, if the clearing routine is so fast, why not just clear |everything and make ALL programs happy? After all, what's a few milliseconds |among friends? When you have a *LOT* of Ram, clearing this still takes a non-trivial amount of time (estimation: about 1 sec per 4M). On a 1M machine however the difference would be hardly noticeable, so this would be a good compromise. A standard trick that can be used on systems that have lots of memory, is to install a large RAM disk, so that perhaps only one M is free. This has the additional advantage that you can load all your standard tools onto the RAM disk, again speeding up you system. |I'm not familiar with the source code--could someone give me pointers on how |to clear the heap and stack, etc. like TOS does? (except using the fast |nullfill routine, of course.) Easy enough. Change the line move.l -58(a6),d0 * # bytes to fill: BSS size into move.l -46(a6),d0 * # bytes to fill: BSS, heap & stack and.l #$fffffffc,d0 * Truncate to multiple of 4. The second instruction is probably not necessary; I used it since GEMDOS clears using longwords (the remainder mod 4 is discarded). Some timing figures on a 520 ST+ (a 1M machine for those who don't know), running a small ( < 2K) program: standard GEMDOS: 1.850 sec. fast nullfill (all): 0.540 sec. (nullfill with the above modification) fast nullfill (bss): 0.340 sec. The actual run took 0.010 sec.; the estimated program load time (from hard disk) is thus 0.330 sec (the program contained no BSS), system overhead not taken into account. Running from RAM disk the figures will become even more interesting. Minor correction on John Zafiris modifications: move #20*20+1,d0 should probably be move #20*20-1,d0 ,since a DBcc counts down until -1 (or until the cc holds). There are two such lines. Leo.