## Forwarded by : [EMAIL PROTECTED] (Joachim Merkel) ## Sender : [EMAIL PROTECTED] (Robert AH Prins) ## Sent at : 30.10.04, 20:17 ## Sent to : /BORLAND/PUBLIC/TURBOPASCAL
"Joachim Merkel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Robert AH Prins ([EMAIL PROTECTED]) wrote: > >> I've added a modified version of WvL's OVERXMS to TURBO.TPL (from my >> OVER-110.ZIP on Garbo) I should have removed it from the final >> build. To solve your problem, remove it using TPUMOVER and all will >> be OK. > > Yes, TPUMOVER TURBO.TPL -OVERXMS did it. > >> I'll add your change to OVER-110 and upload a new version (OVER-120) >> later (today?), FWIW my 386'ified source of WvL's code and the full >> source of the Overlay unit can both be found in that archive, you >> might want to look at them. > > Thanks for adding it. I knew of OVER-110, but hadn't tested it and > forgot that you're the author. Our main problem is to put all that > XMS-stuff together in CrossPoint/FreeXP because we've just added > OVERXMS to other parts using XMS memory. It's not so much work > to rearrange it, but I plan some extensions too. I've uploaded OVER-120.ZIP to Garbo. Don't know when Timo will put it in the proper directory, probably on Monday. <snip> >> Finally, what's your opinion about the product - feel free to email >> me privately if you want. > > In my opinion you've offered long missed solutions but it's not > easy to see the details (without source) or the whole picture > and how far it will be useful for an existing program like CrossPoint/ > FreeXP after many years of development. > So we have to check the possible consequences how (doubled) amounts > are no longer useful or the complexity of some parts of our program > could be minimized or something could be done that results in a better > factoring. I hope I can give you a more precise feedback sometimes. As the initial post already mentioned, the greatest gains can be seen in the handling of longint arithmetic (compared to Norbert's code), in set operations and in (larger) moves. The rest of Norbert's code didn't offer a lot of of other opportunities to optimize it any further. The other major change concerns the emulators, the SW emulator is gone, unless you use one of the extra units, and the HW emulator requires at least a 387. There is scope for further improvements, look at the Fastcode project in borland.public.delphi.language.basm, but I'm not sure if I want to do more, as it would require the insertion of profiling code (as a minimum 'inc [longintcounter]') into every RTL routine and some exit code to print the stats _AND_ a fair amount of people willing to run some real-life programs to actually produce the stats in order to find out which RTL code is used most often and, eg for the Move() (and internal move), the amount of data moved and if it's an overlapping move or not. Given the somewhat limited amount of people that actually gave me any feedback when I asked for beta-testers, I'm not very optimistic... However, if Femme V, Jason B, Rimvydas P, you and whoever else are prepared to provide this feedback, I might be persuaded to do something over the Christmas period. Regards, Robert -- Robert AH Prins prino at onetel dot com ------------------------------------------------------------------------ FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
