From: Michael D. <Fre...@de...> - 2006-07-31 03:32:43
|
<huh, I thought this went to the developer list, but it didn't. Looks like it should.> At 07:48 AM 7/29/2006 +0400, Arkady V.Belousov wrote: >0. In emm386.c you forget remove one space (in "/ *"). And? It's a comment. Is there another one of those #ifdef 0 type things? Because I'm not ready to debate the style of embedded comments again. >1. Bug: wrong handling for clc/stc in some places (they ignored, because > popf follows, thus caller receives "always success") ... I found two. They don't appear to matter in the normal course of things, but if memory got low or ran into partial block allocations, VCPI might run out of memory prematurely when free areas were available. Okay, that was worth the entire thread. I'm going to have to nominate you for next month's FreeDOS Contributor of the Month. What flavor gum you want? >2. Probably, bug: CF not initialized, although comments say so ("probably" > because I not found in RBIL spec for INT 67/87) ... No such spec. It's a FreeDOS-specific redirect of INT 15, function 87h. Anyway, TEST AH,AH clears the carry flag to known state, the STC sets to known state if error. Everything looks fine to me there. >3. Bug: missing popf after @@NO_386 ... Fixed, although I'm not sure a 286 would get there. Does UPX decompressor run under non-386? If not, the decompression code will stop it first. >4. Misfeature: UMBfree does not merges free blocks. Never intended to. I remember the original explanation for this when it came up (it's not my quote following), and I pretty much agree with it. Paraphrasing heavily: UMB blocks are usually handled by DOS (i.e. people do DOS=UMB). Even when they are not, very few applications would allocate and then deallocate UMBs dynamically, they almost always are allocated at startup and stay attached to the allocating application (for good reason). Upgrading the UMB code for merges etc. was therefore considered an unimportant detail at the time. I did make the original code a bit more intelligent about splitting allocation blocks a while back, because there was an application test where it made a difference, but I never tested an application where merges were necessary. As I've said for the past many years, my changes to EMM386 and HIMEM are need-driven, not theory-driven. Show me a real-life application which suffers, and I'll usually make the change. Otherwise, usually not. Perhaps you can rewrite the functionality post-1.0 release. It's a good candidate for detail work. >5. Probably, bug: CF always =0 after XOR, thus, first CheckBlockIntegrity in > next code never called ("probably" because I not very understand idea of > given code - thus, first call to CheckBlockIntegrity may be only > superfluous code, which may be safely removed) ... I removed CheckBlockIntegrity code. I'm still not convinced it makes any difference in the grand scheme of things, but it should make everybody happier. It served its purpose here during early stage VCPI testing. >6. Superfluous code (not need to check, if block at [edi] precedes block at > [esi], because they will be found at next iterations) ... Not superfluous, per previous explanation. It's a very cheap and quick short-circuit, "superfluous" code would be totally without any use. You mean it could have been done better. Yes, it could. I just made it do its work as quickly as possible and left it at that. Since it's called almost never relative to internal functions and since it's a few bytes living in extended memory, optimizations aren't of much use. Literally almost any of the rest of the code would gain more benefit from optimizations. I thought you were rewriting that function, anyway. |