Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!willett!ForthNet From: ForthNet@willett.UUCP (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: Optimization Message-ID: <614.UUL1.3#5129@willett.UUCP> Date: 5 Mar 90 01:41:40 GMT Organization: Latest link in the ForthNet chain. (Pgh, PA) Lines: 98 Date: 03-03-90 (20:01) Number: 1772 (Echo) To: PETE KOZIAR Refer#: 1759 From: MIKE SPERL Read: NO Subj: STUFF Status: PUBLIC MESSAGE Pete, >>there is aa way to shave a few cycles off of UNNEST using > LLES IP, 0 [BP] ADD BP, # 2 Good ssuggestion! No real change on the PC, but on a 286 or 386 a real improvement in performance - 90% faster. Not bad for a word that is part of forth's main loop and executes thousands of times inn a program. I'm going to make the change in kernel1.seq, and I think Tom should include it in his next release. Note: we "popped" 4 bytes, not 2 CODE UNNEST ( --- ) \ Same as EXIT CODE EXIT ( -- ) \ Terminate a high-level definition LES IP, 0 [BP] \ 20 clocks (28 on 8088, 7 on 386) ADD BP, # 4 \ 4 clocks (2 on 386) NEXT === === === ENDD-CODE 24 32 9 instead of: ( Tom''s timings are for an 8086) CODE EXIT ( -- ) \ Terminate a high-level definition XCHG RP, SP \ 4 cycles (3 on 386) POP IP \ 8 cycles (12 on 8088, 7 on 386) POP ES \ 8 cycles (12 on 8088, 7 on 386) XCHG RPP, SP \ 4 cycles (3 on 386) NEXT === === === END-CODE 24 32 17 This is a good example of the effect on programming of improving technology. The 386 does a lot of things in parallel that lessor chips do sequentially. This is aside from the presence of a larger on-chip instruction cache of 15 bytes rather than 3-6. >In thinking back on our conversation, I hope I didn't come across >as being too critical. My comments were supposed to be more on >the level of "have you thought about this..." than "YOU'RE DOING >IT WRONG." No problem. I likke a good diiscuussion; your ideas are among the best in the conference,, and your experience is valuable to all of us. Please continue to be as critical as you feel is justified. I feel more comfortable in assembler than in forth, and I'm sure I get carried away at times. I love forth as a splendid vehicle forr assembler coding and testing, and as you have probably noticed, I try to stick to the low level problems, like screen writing and graphics, and leave the high level programming to others with more experience. Of course, there is an overlap, annd I may tread on higgh level turf sometimmes (especially if I think I can eliminate inefficiencies in the hi level code). Your observations are appreciateed. >major systems that had to be scrappped because they were in >assembly-language, and one of them was supposedly in FORTH even >though all the words were CODE words. We just have to be a little >careful What would have made a difference: better commenting? Did the CPU change? There's a story here that you should tell us. I find that much of the high levvel portion of F-PC is very difficullt to deccipher, untiil I trace things to thee actual machine code, sometimes. I'm glad I don't have to maintain it. >The 80386 modes that allow access to all of memory will cause >problems when used with DOS, DESQview or Windows. Just be aware >that it can be done, "Forth can be an operating system" has been said over and over. This is a good time to see this put to a real test! I don't see much point to a 32 bit forth limited to <640K when most of the work can be donne by hardware built into the 386 chip. We need an asssembler that can access the 386 protected modee features, like multitasking and debugging. >but the problems go beyond the assembly language part of it. Please expand on this point. I know that DOS doesn't know aboutt protected mode. Do the others? How much memory can programs access iin the others? BTW, F-PC has a FOR - NEXT construct, which I've never examined, but Ian's question is not far-fetched. You might take a look at it and tell us hoow it works and what you think of it. ;-) - Mike - ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'