GEnie@willett.UUCP (ForthNet articles from GEnie) (12/22/89)
Message 5 Thu Dec 21, 1989
R.BERKEY [Robert] at 00:58 PST
To: Frank Sergeant
FS> ...I am changing the spelling of LMOVE to MOVEL . I had not
FS> even realized there was a convention in regard to that...
Um, the only "convention" ("a general agreement about basic principles or
procedures") existed in it being a pattern amongst a handful of Forth's I'd
seen, and that Tom Zimmer is aware of the pattern. Given the absence of
counterexamples and your concensus, there does seem to be general agreement.
So much the easier if code is being ported.
What I find curious is that there are a significant number of Forth's; PYGMY,
BBL, and F-PC now included, that use the segment below, even though this goes
counter to the Forth convention of having the least-changing object on top,
such as with a double number and with DO . Preferring the segment-on-top
words, I've added them to my F-PC system. I've found that segment-on-top
systems need the word +UNDER .
FS> Is there a better way to code < & >
There's a way to do it without a branch, but whether this is better may depend
on NEXT and other implementation and processor characteristics.
CODE < ( n n -- Flag ) ( LEAVE BOOLEAN TRUE IF SEC < TOP )
DX POP AX POP $80 #, AH XOR $80 #, DH XOR DX, AX SUB
AX, AX SBB AX PUSH NEXT END-CODE
FS> I think part of what I'm saying is that a standard evolves when we
FS> search for what is right rather than when we search for a standard.
Yes, that sounds related to Wirth's concern that standards get put in place on
languages prematurely. Everybody seems to have a different idea of what
standards are. The MUMPS ANS committee notes that they never remove language
features. But there's never been a Forth committee to weigh that as a
fundamental principle. Maybe it would be more realistic and constructive for
the Forth committee to specify Forth as a living language.
FS> ... ( a - a'). Should it be cmTYPE or TYPEA or what? Any
FS> ideas? Anyone know any history about Chuck's ( a - a') vs
FS> ( a # -)? I'm also adding COUNT ...
In F-PC, the operator to convert an address and length string back to a
counted string is ">$ . I've picked up on that to use $ in names which
reference a counted string in memory, and " when there is an address and
length on the stack.
Chuck's TYPE is especially interesting in the Pygmy word dot" .
POP TYPE PUSH ;
Purdy darn clever. But in PYGMY most of the time TYPE is followed by a DROP ,
and it can only be used with byte-counted strings. For general use, I don't
see it. Me, I'm moving toward address and count, such as the BASIS >NUMBER in
place of CONVERT .
Your comment about Chuck's COUNT has me curious as to what his does.
FS> opening a new file - error... I have FILES=20 & BUFFERS=20 in my
FS> CONFIG.SYS file. Any chance you are using a smaller number...
Yes, that's it! FILES=12 was in CONFIG.
FS> ...maybe I should name nothing with a "U" prefix as why bother
FS> if unsigned operators are the only ones in the system.
How about readability and portability.
There exists some standard's sentiment to redefine the 1982 division names as
limited to use on the range of numbers 0..32767. This would mean that the
implementations of the unsigned Pygmy words as well the 1979 division words
would fall within the scope of the standard. It might be useful to be aware
that for this range of numbers division works the same on all Forths. But I
think that for the Standard, the idea is superficial.
------------
-----
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)
Category 1, Topic 45 Message 6 Sun Dec 24, 1989 R.BERKEY [Robert] at 10:53 PST Re: How quickly they forget. FS>> ...I am changing the spelling of LMOVE to MOVEL ... RB> ... Given the absence of counterexamples... Oops, there is at least one counterexample. PC83 uses a trailing "L" for segment-on-top words. ----- 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'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)
Category 1, Topic 45 Message 9 Sat Dec 30, 1989 F.SERGEANT [Frank] at 15:44 CST MOVEL, LMOVE, L@, @L, LC@, C@L SP> So by all means, keep doing it @L. Steve, I haven't really started calling it @L yet. I'm still using L@. I just think consistency suggests that if I call LMOVE MOVEL that I should also call L@ @L. I actually prefer the name LMOVE to MOVEL, however, I have changed it to MOVEL in v1.2 of Pygmy. And thanks for the extra history on this subject. DaR>The reasoning as it is explained in MASM is so that it is DaR>easier to add offsets to a FAR address. I am suspicious of any reasoning offered by Microsoft. RB> Oops, there is at least one counterexample. RB> PC83 uses a trailing "L" for segment-on-top words. Bob, you were my rock in this sea of confusion. Now, I suppose I'll drown. ZE> However, from a human User/programmer point of view having ZE> the segment followed by the offset seems the easiest to handle. ZE> As I have said ... I prefer the naming as LMOVE & LFILL Zafar, I agree with both points. ZE> ... I would think the top of the stack is the place ZE> ... to see the parameters that are apt to change most. ZE> ... I must be missing something. For clarity I prefer SEG OFFSET L@ to OFFSET SEG L@. Although maybe I could live with either. However, here is what Bob meant, I think: Suppose you want to access video memory, you could write a general purpose word for it like this : VID@ ( offset - byte) $B800 LC@ ; more easily if the least changing number was on top. If the least changing number was on the bottom, you'd have to write it this way : VID@ ( offset - byte) $B800 SWAP LC@ ; It is similar to the benefit in writing DO LOOP words where the starting index is specified in the word but the limit is not, eg : STARS ( # -) 0 DO STAR LOOP ; To summarize, you all make a lot of sense. Currently I prefer the leading L but with seg below (preceding) offset. But, I'm going to watch for situations where have the seg on top would be better. The best solution might be to quit using Intel processors. -- 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'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/06/90)
Category 1, Topic 45 Message 10 Thu Jan 04, 1990 F.SERGEANT [Frank] at 00:24 CST PYGMY FORTH version 1.2 I recently uploaded the newest version of Pygmy as file #1939 PYGMY12.ARC. It "should" automatically adjust to the type of monitor you have (either color or monochrome). It works fine on my monochrome system but I haven't had a chance to test it on a color system yet. I might get a chance to try it sometime this week. So, feel free to hold off downloading it until we find out if it works as I expect on color systems. This new version has lots of little, minor details tended to, such as whether < & > return correct values. The flag returning words are faster and smaller, based on Bob Berkey's code. The new file HASH.SCR contains optional hashed dictionary search code that can be loaded on top of Pygmy and turned on and off. This cuts compile time by perhaps 1/3rd. The unsigned mod operators have been renamed with a U ( eg U/MOD). BOOT is vectored so you can set up a turnkey application more easily ( eg ' MYAPP IS BOOT SAVE MYAPP.COM ). I'll post a message when I've tested it on a color machine. If anyone tries it before I do, please post a message. -- 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'