[SPAM] - Re: Help With an Erastz-11 DLL - Found word(s) remove list in the Text body

Jerome Fine replies: I have contacted John and he mentioned TASM (from Borland). At one point, I probably had that assembler on an AT, but it was so long ago, the AT died and it probably did not support 386 instructions in any case. As far as I understand the code for EMEM.ASM, it is all very simple 386 type instructions without any macros. There are only 271 lines of code in total with over 100 lines of comments and less than 140 lines of actual code - the rest being directives and subroutine entry points. It is a relatively small program when I consider that it can make more than a GigiByte of Pentium memory available addressed by either byte or 16 bit word. Since the EMEM.ASM file is only 7,148 bytes and the EMEM.DLL file is only 1060 bytes, I doubt that John would consider the EMEM concept anything other than a shell for how to write a DLL for E11. But I don't wish to make the file available in a public manner. What I should be able to do is to take advantage of the considerable CPU power of the Pentium 4 while at the same time writing most of the code for the PDP-11. At the same time, I understand it can never execute on a real DEC PDP-11 mostly due to how long it would take to do anything useful if I write PDP-11 code for the inner loops that will done at very high speed on the Pentium 4. What may be able to really speed things up is if I am able to effectively use the 2 MegaByte L2 cache on the newer Pentium 4 CPUs with a 1066 front side bus (whatever that means). While the work space in EMEM memory will likely be bit a bit map of about 404 MegaBytes, the concept I hope to use may be able to split that into portions that fit into the cache. What I don't know is whether the overhead of repeating each inner loop will be worthwhile. There are about 50 million inner loops. Each inner loop must be executed between about 10 times and about 10 million times. (Maybe now you understand why I estimate a year to execute!) However, when the inner loop is executed less than 1000 times (over VERY widely scattered points in that 404 MegaByte bit map or only about twice per portion which fits into the cache), it seems doubtful there would be sufficient improvement. That seems to leave a small fraction of the inner loops (only about 100,000 of them - which end up using most of the total time in any case which is why splitting the work space into portions which temporarily fit into the cache may be so very useful). Can anyone comment on how much of a speed improvement there might be by modifying the code so that data is accessed via cache rather than from memory? I will locate the assemblers that you suggest and try them! THANK YOU!!! Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.