Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!willett!ForthNet From: ForthNet@willett.UUCP (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: Category 1, Topic 45 Message-ID: <105.UUL1.3#5129@willett.UUCP> Date: 4 Jan 90 21:08:48 GMT Organization: Latest Link in ForthNet Chain Lines: 99 Category 1, Topic 45 Message 7 Sun Dec 24, 1989 F.SERGEANT [Frank] at 15:10 CST Bob, SP! ( -) vs SP! ( a -) RP! ( -) vs RP! ( a -) In my reply to your first comments I ran out of steam before I got to these. I had not remembered these taking arguments and just looked them up in the fig-FORTH INSTALLATION MANUAL and sure enuf they didn't - back then. Now, I don't know. MOVEL ( seg off seg off # -) vs LMOVE ( off seg off seg # -) @L ( seg off - u) vs L@ ( off seg - u) C@L ( seg off - c) vs LC@ ( off seg - c) Currently I'm using L@ ( seg off - u) but if I'm going to change LMOVE TO MOVEL I should probably start spelling L@ & LC@ as @L & C@L I suppose. I'm sure I picked seg on the bottom so I could write the parameters as I think them ( eg 0100:ABCD ). I had not considered needing to put the seg but not the offset into a word, similar to : STARS ( u -) 0 DO STAR LOOP ; I'll have to see if I need to do that anywhere. Perhaps I should solve it by switching to another processor, ha ha. Thanks for the new version of <. I'm repeating it here, modified for Pygmy. HEX CODE < ( n1 n2 - f) ( true if n1 is less than n2 ) ( n2 is already in BX) ( cycles bytes) AX POP, ( n1) ( 12 1 ) 80 #, AH XOR, ( flip sign bit of n1) ( 4 3 ) 80 #, BH XOR, ( flip sign bit of n2) ( 4 3 ) BX AX SUB, ( subtract n2 from n1) ( 3 2 ) BX BX SBB, ( convert borrow to flag) ( 3 2 ) NXT, ( 27 3 ) END-CODE So, it takes 53 cycles and 14 bytes. It is faster than the jump method I'm currently using but takes two more bytes. The jump method takes either 52 or 62 cycles ("average" of 57 cycles) and 12 bytes. Are 4 cycles worth 2 bytes? I have no idea, and doubt that it makes much difference. In certain situations it might have some value for < to take the same length of time regardless of whether it is true or false. But, on the 8088 where we (I at least) don't know how long anything takes because of the variables of interrupts and memory refresh and pipelines, I doubt that a consistent < would make any difference. Anyway, I appreciate your showing me a new approach. I started thinking about it and came up with the following. It is slower and longer still, but I wanted to show it to you in case it inspires you to see any short cuts. CODE < ( n1 n2 - f) ( n2 is already in BX) AX POP, ( n1 12 1 ) AX CX MOV, ( save n1 2 2 ) BX AX XOR, ( AX sign bit is now true only if signs ) ( of n1 & n2 are different) ( 3 2 ) CWD, ( extend that sign bit thru DX) ( 5 1 ) BX CX SUB, ( n1 - n2) 3 2 ) BX BX SBB, ( extend borrow thru BX 3 2 ) DX BX XOR, ( flip flag if signs were different) ( 3 2 ) NXT, ( 27 3 ) END-CODE This takes 58 cycles and 15 bytes. So you're suggesting TYPE$ ( "type string") for ( a - a') and TYPE for our usual ( a # -). I like that. Yeah, I really like the POP TYPE PUSH trick. I need to see if it is used enough to justify having TYPE$. Here is the COUNT that you asked about from cmFORTH : COUNT ( n - n) 7 TIMES 2/ 15 AND ; It extracts the cell count from the 1st word of a string. The "7 TIMES" forces the 2/ to be performed 9 times. It is used to get the cell length from the 1st word of a name field in the dictionary. Here's an example of its use : -FIND ( h n - h t | a f) HASH OVER @ COUNT 6 I! BEGIN @ DUP WHILE SAME UNTIL 0 EXIT THEN -1 XOR ; FOLDING OF COMPLEXITY (or OUT OF THE BLUE) I really like to make trade offs such as cutting the length of a code word and speeding it up at the same time. It makes the decision to do it very easy. Sometimes I'm in a bind and have to do something. Often there is a brute force method that "solves" it but is not pretty, but sometimes I can see a pretty method that not only "solves" the problem, but simplifies everything involved with it. That's what I like. I think of it as a folding of the complexity. A shorter, faster, simpler approach. I don't see these often enough! The more usual tradeoff (probably the only kind that can properly be called a "tradeoff") involves using more memory than I'd like to in order to get the speed or functionality I have to have. Is a view field worth its cost, that sort of thing. -- Frank ----- This message came from GEnie via willett through a semi-automated program. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'