ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)
Date: 12-28-89 (08:16) Number: 1553 (Echo) To: R.BERKEY [ROBERT] Refer#: 1494 From: ZAFAR ESSAK Read: NO Subj: PYGMY FORTH Status: PUBLIC MESSAGE I have read the comments by you and Frank regarding LMOVE and MOVEL naming conventions and the premise RB> the Forth convention of having the least-changing object on top However, from a human User/programmer point of view having the segment followed by the offset seems the easiest to handle. The representation on the stack would automatically follow with the segment below the offset. As I have said in prior messages I prefer the naming as LMOVE & LFILL and (now historically) LCMOVE LCMOVE> because the leading "L" serves to identify a family of words which can be found quickly in a search. Having two names based on position of parameters on the stack will serve to confuse newcomers too, I'd bet. As for the premise, I would think the top of the stack is the place where one would want to see the parameters that are apt to change most. I must be missing something. --- * Via Qwikmail 2.01 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- 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/11/90)
Date: 01-09-90 (19:46) Number: 235 To: ALL Refer#: NONE From: PETE MACK Read: HAS REPLIES Subj: PROBLEM WITH HANDLES.. Status: PUBLIC MESSAGE please look at handles.arc.. I am having trouble opening more than 15 files. Using int 21-funct 67.. Thank You.. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 Date: 01-09-90 (22:11) Number: 236 To: PETE MACK Refer#: 496 From: RAY DUNCAN Read: NO Subj: PROBLEM WITH HANDLES.. Status: PUBLIC MESSAGE I looked briefly at your test program. I don't have time to figure out exactly what is wrong with it, but I can assure you that Int 21H Function 67H does *definitely* work as advertised. It is only available in MS-DOS 3.3 and later though. My guess is that even though you think you are restricting the amount of memory assigned to the program with the Linker switch, this is not really happening, and the program is getting allocated all the available memory. in such a case Int 21H Function 67H will fail because it can't allocate a new block to hold the expanded handle table. It could also be that the runtime library's support for this is flakey. If you use int86 to resize your program's memory block (say, down to 128 KB maximum if you are small model) with function 4ah then ask for more handles with function 67h it should work as expected. I just tried it interactively from PC/FORTH and it worked fine. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 ----- 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'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/14/90)
Category 1, Topic 45
Message 24 Tue Feb 13, 1990
F.SERGEANT [Frank] at 01:01 CST
To Doug Philips re changing registers in Pygmy CODE words
Here's a quote from screen 2102 (in ASM.DOC):
If your routine disturbs CS, DS, BP, SP, SI, or BX
it must restore it. The direction flag must be left clear.
Yes, it is perfectly proper to change the other registers without
restoring them or to change the above registers if you restore them. Forget
about CS, you aren't going to change it. Suppose you want to do a DOS Int $21
call that needs other registers set up than the built in words DOS or DOS2
provide. For example, you might want to use function $40 "Write to a File or
Device" and you want to use a buffer outside of Pygmy's segment.
CODE WRITE-BUF
( buf-offset buf-seg handle count - #bytes-written f)
BX CX MOV, ( move count from TOS to CX)
BX POP, ( put handle in BX)
AX POP, ( put seg temporarily in AX)
DX POP, ( put offset in DX)
( now we have all our parameters off the data stack)
( and it is free for us to use to save DS )
DS PUSH, ( save DS)
AX DS MOV, ( reload it with segment)
$4000 #, AX MOV, ( tell DOS we want function $40 )
$21 INT, ( do it )
( now AX holds bytes actually written if carry is not set)
( or an error code if carry is set )
DS POP, ( restore DS )
AX PUSH, ( push either count or error code )
BX BX SBB, ( convert the carry flag to a forth flag of -1 or 0 )
( this might have been clearer if written this way )
( CS, IF, -1 #, BX MOV, ELSE, BX BX SUB, THEN, )
NXT,
END-CODE
Note that we don't bother preserving AX or CX or DX. BX is altered, but
carefully, as we must see that it holds Top of Stack. DS was saved before the
$21 INT, and restored afterwards. I haven't tested the above routine put it
should get the general idea across. You could change the code to accomodate
a different order for the operands.
You know what must go in the various registers by consulting a reference
book on DOS calls. I'm looking at a Microsoft programmer's reference manual
for MS-DOS 2.0.
And, what's the worst that can happen if you screw it up? Probably just
wiping out your hard disk. Current backups might add to your peace of mind,
but Forth programmers live dangerously and crash the system all the time.
-- Frank
-----
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'dwp@willett.UUCP (Doug Philips) (02/14/90)
In article <460.UUL1.3#5129@willett.UUCP>, F.SERGEANT [Frank] writes: > Here's a quote from screen 2102 (in ASM.DOC): > > If your routine disturbs CS, DS, BP, SP, SI, or BX > it must restore it. The direction flag must be left clear. (Blush). I just assumed that that info should have been in TECH.DOC. > Suppose you want to do a DOS Int $21 > call that needs other registers set up than the built in words DOS or DOS2 > provide. For example, you might want to use function $40 "Write to a File > or Device" and you want to use a buffer outside of Pygmy's segment. That's, in fact, one of the things I wanted to do. I'm still struggling with how to factor my end application, but so far I'm working bottom up and starting with these kinds of words. > You know what must go in the various registers by consulting a reference > book on DOS calls. I'm looking at a Microsoft programmer's reference manual > for MS-DOS 2.0. I have 'The MS-DOS Encyclopedia' which purports to cover 1.x -> 3.x. > And, what's the worst that can happen if you screw it up? Probably just > wiping out your hard disk. Current backups might add to your peace of mind, > but Forth programmers live dangerously and crash the system all the time. Whew, I feel soooo much better now! :-) Thanks for the info. -Doug --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/11/90)
Date: 03-08-90 (22:39) Number: 3012 (Echo)
To: IAN GREEN Refer#: 3011
From: MICHAEL HOBSON Read: NO
Subj: CMFORTH FOR MS/DOS Status: PUBLIC MESSAGE
[Note, Pygmy is also available on SIMTEL20 --dwp]
Frank Sargent has written a marvelous MS/DOS Forth called Pygmy, that is
supposed to be a very close approximation of cmForth (Chuck Moore Forth)
that is available for downloading here on this board. PYGMY12.ZIP is
the latest version, I believe. It comes with all the source code, a
metacompiler (allows you to customize Pygmy with your own enhancements
and/or revised kernel word definitions), an 8086 Assembler and a small
screen editor built in. The executable is only about 30 Kbytes!! If
you re-metacompile it and leave out the editor and assembler, it fits in
about 12 Kbytes!! Don't make the mistake of writing this thing off as a
toy - there are around 400 built-in words in this little mighty-mite.
"The Elf" [^]-[^]
\---/
Elf - A wise (?) and helpful variety of magical being.
P.S. -- as supplied, a full 64K segment is consumed at run-time, but
this can be easily changed by altering a couple of constants in the
source and metacompiling. I shrunk a copy (without the screen editor)
to about 20K of run-time RAM with no problems. This is small enough to
build really compact TSR programs with.
-----
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/18/90)
Category 1, Topic 45
Message 26 Sat Mar 17, 1990
F.SERGEANT [Frank] at 15:46 CST
[ PYGMY 1.2 is available on SIMTEL20. SIMTEL20 files are accessible
both via direct FTP (for internet sites) and via BITNET listserv's
(email servers) to uucp/mail only sites. See the OLIS SIMTEL20 file
for more information. -dwp]
RC> email me or post the source for PIGMY Forth since I can't access RC> the
archived versions?
to Rob Chapman on UseNet
Is the problem lack of access to an MS/PC DOS machine or lack of access
to GEnie & the xCFBs or ... ? Or is it just that Pygmy is on the bulletin
boards in ARC format?
I enjoyed looking at your botFORTH postings and I'd like to return the
favor. Can you write me (Box 1613, San Marcos, TX 78667) with your address
and the above answers (& perhaps the below requested article)?
I gather from the recent FORML proceedings that "bot" stands for "bundle
of technology." I'd like to hear (read, etc) more about that. How about
writing up all the details you can?
By the way, I changed Pygmy's FOR NEXT to the zero does it zero times as
you suggested. It will appear in PYGMY version 1.3 if I issue another
version.
-- Frank Sergeant
-----
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/18/90)
Category 1, Topic 45
Message 27 Sat Mar 17, 1990
F.SERGEANT [Frank] at 15:47 CST
MB> "Cleverness" (aha! this just happens to work so I'll use it) MB> at the
expense of clarity is one of the things that gives Forth MB> a bad name in the
computer community at large.
To Mitch Bradley on UseNet
Yes, you are right, thanks. The tiny savings by not defining a C@+ or
whatever cannot justify the negative mnemonic value of using COUNT
inappropriately. I now plan to correct this.
The next problem is that I like the name C@+ for this ( a - a+1 c) while I
think botFORTH & cmFORTH would tuck the char under the address, which is
useful also. Tentatively I'll go with calling it C@+.
-- Frank
-----
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'wmb@MITCH.ENG.SUN.COM (03/23/90)
> The next problem is that I like the name C@+ for this ( a - a+1 c) > while I think botFORTH & cmFORTH would tuck the char under the address, > which is useful also. Tentatively I'll go with calling it C@+. Yes, both ways ( adr -- adr' char ) and ( adr -- char adr' ) have their uses. If C@+ is already used in other systems, by all means try to be compatible. If you need a different function, call it something else. NEXTBYTE seems like a good name to me. Cheers, Mitch Bradley
ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/29/90)
Category 1, Topic 45
Message 29 Thu Jun 28, 1990
F.SERGEANT [Frank] at 02:01 CDT
Len, thanks for the comments. I'm sorry I misunderstood about the disk
being one giant file, but glad to find out you like how Pygmy handles files.
(It was more amusing, though, when I thought you objected to it being one
giant file at the same time Robert objected to it NOT being one giant file.)
About NUMBER, I have a few random thoughts but no definite suggestion:
I, also, like that it *uses* the count rather than requiring a space at
the end of the string. It's always seemed silly to me to use a counted
string and ignore the count and require that it actually be a delimited
string.
The only thing that makes the string a bad number is one of the
characters not being a valid digit, so I see a certain harmony in -DIGIT
blowing up if it gets a bad digit. I think this is just a mental trick. If
I *prefer* it the way it already *is* then I don't have to do any work to
change it! With that disclaimer, I'll continue.
-DIGIT blowing up is entirely satisfactory when the user uses a
collection of Forth words as tools. That is, he types a number and then a
command. It only becomes a problem when the application prompts the user for
a number. It is a question of who is driving whom. Since we are going to
the trouble of giving the user a 'turnkey' system, it seems sloppy to allow
him to make a mistake that crashes the system.
I am not arguing against this. I think there are many times when we
*must* insulate the user & the application from each other. I have some
regret over it, though. One of my favorite thoughts (not original) is that
sometimes you need things but sometimes you only need things because your
things need things. So, *we* don't need any fancier error
recovery/prevention, unless we've already added the complexity of a fancy
user interface. Like I said, I'm not trying to talk us out of fancy user
interfaces. I think we have to have them to stay competitive (but I'm not
quite happy).
The Michael Ham & Mike Elola & Glenn Linderman articles in FD, etc have
been attempts to deal with this very problem. One approach was to detect the
error, as you've suggested, without blowing up. Another is to refuse to
accept an invalid keystroke. It doesn't seem that either of these properly
belongs in NUMBER.
If I were to make a suggestion (you've heard of Boolean Logic, and Ill
Logic, and CMOS Logic, and Mickey Mouse Logic, well this is based on Inertial
Logic as I discussed earlier) it would be to leave NUMBER & -DIGIT alone.
They do what they do just fine. Instead add a new word to do just the
testing, just when it is needed. NUMBER? might be an acceptable name - or
VALID? or VALID-DIGITS?. Now, I'm guessing that this would find use
exclusively for users using decimal base. It might not be worth making it
general by consulting BASE, but it could be. It would take a string and
check it for valid digits and return a flag. Here's a quick version that
omits checking for minus signs, etc.
: VALID? ( a - f)
COUNT FOR ( a) C@+ '0 '9 WITHIN WHILE NEXT DROP -1 ( f) EXIT
THEN ( a) DROP ( ) POP ( index) DROP 0 ( f) ;
There is more to user input validation than this. Sometimes negative
numbers are ok, sometimes only a certain range is ok, etc.
Thanks for the suggestion. I'll add it to the stack as I re-work Pygmy
for version 1.3.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (07/29/90)
Category 1, Topic 45
Message 27 Sat Jul 28, 1990
F.SERGEANT [Frank] at 10:38 CDT
Alan,
To change colors in Pygmy, type $bf00 ATTR ! where b is the background
color and f is the foreground color. For example, $6000 ATTR ! for black on
tan, $6A00 ATTR ! for green on tan, $0A00 ATTR ! for green on black.
Once you find the colors you like, edit $6000 ATTR ! into (BOOT on scr
#3074, then do
3074 LOAD
SAVE <newname>.COM
so the new colors will come up automatically next time. (And/or make the
change to RESET on scr #3075, replacing HEX 0700 with your number, and regen
Pygmy.)
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)
Category 1, Topic 45
Message 29 Sun Aug 05, 1990
F.SERGEANT [Frank] at 11:08 CDT
Doug,
Thanks for answering what you did & didn't like about Pygmy Forth. I
appreciate such comments and take them seriously. I hope there will be some
improvements in the next version.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/10/90)
Date: 08-02-90 (03:46) Number: 3617 (Echo)
To: FRANK SERGEANT Refer#: NONE
From: CHRIS WATERS Read: NO
Subj: PYGMY 1.3 FORTHCOMING Status: PUBLIC MESSAGE
FS: To Chris Waters (of xCFB, I think)
Hi Frank,
Nice to hear from you. I have no idea if I'm "of xCFB" or not.
What is it (them? her?)? I'm connected here through MetroLink (one of
the several networks sharing this conference) if that's what you mean...
FS: I am in the process of revising Pygmy
Let me see - the version I have is ... 1.1. Haven't seen 1.2 yet,
but I'll make an effort to get 1.3 as soon as you release it. I presume
we can look forward to an announcement here?
FS: what would have made it easier for you to feel oriented and in contr
Well ... as long as you ask ... I'd like to see the glossary
grouped by category, rather than just in dictionary order. It would
make it a lot easier to see what's there and what's not. Also, it would
be nice if the help files explained how to print screens, for those of
us who prefer to browse through hard-copy when we're getting started.
As a *really* minor issue, I think that SHOW2 should use Epson
printer codes by default, not Oki. It's certainly my impression that
Epson compatible printers are the most common.
But none of these are major issues (and some may already have been
addressed in 1.2). Most of my disorientation comes from being
unfamiliar with the dialect and not having spent a lot of time with the
system yet. Once I get over the learning curve, I suspect I'll give
Pygmy a lot of use.
Anyway, thanks for your message, and thanks for an excellent little
system. I'll keep my eyes on this space for further developments.
ttyl,
Chris
-> MegaMail(tm) #609:~ Nothin' left to do but :-) :-) :-)
1.20
PCRelay:SNAKEPIT -> #150 MetroLink (tm) International Network
4.10 Snake Pit*408-287-2353*San Jose, CA*HST/v32
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/13/90)
Category 1, Topic 45
Message 31 Sat Aug 11, 1990
F.SERGEANT [Frank] at 17:31 CDT
To Chris Waters (of MetroLink, I think, duh)
Your message was relayed thru the an "xFCB" (I assume the East Coast Forth
Board), if I understand things now.
Thank you for your suggestions. That's just what I wanted to know. I'll
plan to revise the glossary along the lines you have suggested. I am
thinking of having the *.COM file include more of the loadable utilities so
that they'll be ready to go for someone new to Pygmy. Then he can trim off
the ones he doesn't need, in order to cut it down to a minimal size again.
You have a good point about the Epson codes being more universally useful.
Naturally, I have an Okidata printer. I've factored out the printer setup
and will try at least to explain in the HELP file how to print to the Epson
and how to print out the source code.
My feeling is that ver 1.2 is MUCH better than 1.1 but that, at this
point, you might as well wait for 1.3. I haven't been completely happy with
the file handling (in either 1.1 or 1.2) and have made some substantial
changes for 1.3. As it stands now, files no longer have to be opened "in
order" - you can have the 1st file use screens 1800 thru 2200 and have the
next file use 300 thru 312 and then skip one or more slots and open another
file with screens 900 thru 950, and so forth. Now all aspects of file
handling is done relative to the files "unit" number. So far I've been
pleased with this new approach. It goes something like this:
NAMEZ: MYFILE.SCR
( NAMEZ: in a defining word that creates a Forth word
that returns the address of its own name. The string
ends in $00 so as to be a suitable "asciiz" file name.)
FILE-NAME: DATA1 C:\FORTH\WORK\OLD\YOURFILE.SCR
( FILE-NAME: in a defining word that creates a Forth word
that returns the address of the following asciiz string.)
3000 MYFILE.SCR 7 UNIT
( plug the name & starting blk# into unit #7)
900 DATA1 9 UNIT
( plug the name & starting blk# into unit #9)
Then, whatever you want to do with a file is done with its unit# (or
with the block numbers).
7 OPEN ( open the file MYFILE.SCR)
9 MAKE ( create the empty file named YOURFILE.SCR in
the C:\FORTH\WORK\OLD\ subdirectory)
100 9 MORE ( extend that file with 100 blank screens)
9 >EOF ( position to end of file)
9 >BOF ( posititon to beginning of file)
9 EXISTS?
( find out a non-zero length file of that name is present)
3000 3050 SETTLE ( make the heavy screens in this range in
MYFILE settle to the bottom - the light
screen - with only blanks - float to the
top)
9 CHOP ( truncate MYFILE.SCR so that all trailing blank
screens are chopped off. Compare this to -TRAILING
on strings.)
Also available are a few words to make sequential file access easier,
such as
FILE-WRITE ( a #bytes unit# -) ( for sequential file writes)
FILE-READ ( a #bytes unit# -) ( for sequential file reads).
As I was doing this, I thought "hey, maybe this is similar to the file
handling in BASIS. If so, maybe I can be "compatible" with the "standard" at
no great mental & emotional cost to myself!" So, I got out BASIS 11 and
looked over the file words. Nope! I can't do it. It hurts too much. Maybe
I'll change my mind. In the meantime, if you want it, the tools in Pygmy 1.3
will let YOU do it. Maybe I'm wrong and maybe I'll come around, I don't know
yet.
After I got the file handling changed around and a few other things, I
got interrupted by real work. This is delaying ver 1.3 slightly, but I'm
using the new Pygmy, so this gives me a chance to exercise it.
Really about the only thing I dislike concerning BLOCKs for source code
is for CODE words. High level words seem to fit nicely in a block, but some
of the longer CODE words, where the assembly language is a little obscure to
begin with, and extensive comments are especially important, MUST spread
across a number of blocks. I have no real solution for this yet except "be
neat, and put in those comments, and spread across as many screens as it
takes." Am I leaning toward variable length, CRLF delimited, line-oriented,
sequential files for source code? I don't think so, but ... Emotionally, I
am leaning toward the-entire-disk-is-one-BLOCK-file. I'd still keep SETTLE
and COPIES but almost all the rest of the file handling could disappear! I
don't see any way in H.ll to do it, though, as I am "forced" to co-exist with
DOS. If I see a (pretty) way around this, BANG! goodbye DOS. (I don't
envision any such changes for ver 1.3, though.)
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/16/90)
Date: 08-13-90 (12:14) Number: 3647 (Echo)
To: FRANK SERGEANT Refer#: 3631
From: CHRIS WATERS Read: NO
Subj: PYGMY FORTH Status: PUBLIC MESSAGE
[After several attempts with the same results I concluded that the
"transmission" errors herein had already occurred before I got a hold
of it. Sorry for any inconvenience. -dwp]
FS: To Chris Waters (of MetroLink, I think, duh)
TMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
It's ok, Frank, I'm really none to clear on all these connections
myself. It boggles me how many networks meet here - I've given up
keeping track. <g> FWIW, your messages have an East Coast Forth Board
tag when they appear HERE (Snakepit BBS).
I pretty much call this board just for ForthNet. I have another
Sysop I'm trying to persuade to carry this conference. Of the systems
I've shown him, he's found Pygmy the n_fQ@%5AIMMRY9JA!=U!Qd{U"5RA+k+dto know that.
FS: Thank you for your suggestions. That's just what I wanted to know
TMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
Glad I could be of service. I'm suprised nobody else jumped into
this thread. I figured your post would generate lots of responses, but
mine was the only one I saw.
FS: My feeling is that ver 1.2 is MUCH better than 1.1 but that, at
3 this point, you might as well wait for 1.3.
TMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
Hmm, ok, 1.1 was pretty impressive. I'm ready to be stunned. :)
As far as the file vs. block access goes, I waver back and (ahem)
forth about this issue. Blocks certainly make make things simpler, e.g.
editing, virtual memory, etc. OTOH, files provide compatibility with
worlds full of development tools. And I get tired of re-inventing the
wheel. But as long as the system source is available, I can experiment
freely, using either approach as I desire. Actually, since most of my
high-level definitions are 2 or 3 lines long, kilobyte blocks are too
large. And, as you pointed out, they are too small for assembler
definitions.
I haven't seen BASIS yet. I'm going to have to check this out one
of these days. Some of the comments I've seen around here worry me
slightly. I got a couple of key things pushed throug8n the
83-standard, and I'm ready to try again if need be. Ghod I hope they
gave up on floored division. :)
Chris
PCRelay:SNAKEPIT -> #150 MetroLink (tm) International Network
4.10 Snake Pit*408-287-2353*San Jose, CA*HST/v32
NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/20/90)
Date: 08-16-90 (07:40) Number: 3663 (Echo) To: FRANK SERGEANT Refer#: NONE From: JAN HOFLAND Read: NO Subj: 68HC11 & PYGMYFORTH Status: PUBLIC MESSAGE Hello Frank, First, I want to thank you for the 68hc11 assembler you implemented for Jack Brown. Jack tells me that you did it not ever using the chip. Well done! Second, thanks for pygmy forth. When a new version is available, I would like to receive such a copy. By training and experience, I am a digital hardware designer. I am trying to learn enough about the inner workings of forth to eventually write a simple version myself. Your efforts and thoughtful comments regarding how things (should) work help. Regards, Jan Hofland --- ~ EZ 1.27 ~ NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/20/90)
Category 1, Topic 45
Message 34 Sun Aug 19, 1990
F.SERGEANT [Frank] at 13:24 CDT
To Chris Waters 1 of 2
CW>I haven't seen BASIS yet ... Ghod I hope they gave up on floored
CW>division. :)
I can't imagine what you are talking about. The standards committee is
composed of the finest minds in the Forth community. They have the
experience, insight, and level-headedness to optimize the standards process.
In addition, they are completely in touch with the vendors and, through the
vendors, with all the customers (the users of Forth) of the vendors. Those
customers are countable. By that I mean, the committee can say "so many per
cent of all Forth users are now using [floored division or zero'd division or
this vocabulary structure or ...]." I believe it is through this method that
they are able to determine that the Forth-83 standard was NOT a success as it
is NOT used by almost all the customers of the vendors, and therefore the
current committee cannot merely update the Forth-83 standard with minor
changes (such as "like, we said 16 bits - well, like, do it with 32 bits if
you want to, No Problem!"). Without this countability it would be much more
difficult to determine that Forth-83 was so terribly unacceptable to so many
people.
I can just hear you complaining now that this method of counting excludes
the few users of L&P's F83 (and the few users of its few derivatives such as
F83X, Y, etc & F-PC), some of which probably DO find the Forth-83 standard
acceptable. Surely, and the sample made up from the vendors' to represent
all of them. Besides, on another level, these people (users of non-Vended
systems) may REALLY not count. (If the current countable Forth users are not
felt to be a sufficiently large sample, users of C and Pascal could be
considered as well, I suppose.)
Of course, in the previous paragragh I'm not being entirely serious, or
fair. More and more, as I search for my "perfect" Forth, I see very similar
problems to those facing the standards committee. Further, various of its
members such as Mitch Bradley, post messages that explain courteously, and at
length, the reasoning and pressures behind their decisions. I find I have to
agree with them in many ways. If I were on the committee I would probably say
ok ok I'm tired, let's finish it. I would like to see an (accurate) press
release that says "the entire Forth community met to consider a standard and
agreed unanimously not to even HAVE a standard." But, I suppose it wouldn't
be unamimous.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/20/90)
Category 1, Topic 45
Message 35 Sun Aug 19, 1990
F.SERGEANT [Frank] at 13:25 CDT
To Chris Waters 2 of 2
CW>I haven't seen BASIS yet ... Ghod I hope they gave up on floored
CW>division. :)
All of this is just an introduction to a discussion of floored vs zero'd
division. I believe that the way it currently stands they require two new
words, one for each way, and you define / etc in your application to use the
method you choose.
I've recently been pouring over Knuth's book and Roedy Green's assembly
listing on division and thinking about and worrying over division. The one
thing I've learned is that I ain't never gonna be a mathematician. I believe
that in the history of man's mathematical progress there was a very long
period of time before negative numbers were accepted. Now we have no
(little?) trouble grasping them.
Now let's take division. When all the numbers are positive integers and
we want a quotient and remainder we are all agreed. The quotient is
"floored" (if the real quotient is not an integer, the lower of the two
integers it falls between is chosen) and it is also "truncated toward zero"
(of those same two integers, the one nearest to zero is chosen). The
remainder is the positive integer difference between the dividend and the
product of the chosen integer quotient and the integer divisor. What could
be simpler?
If we want only a quotient (no remainder), and the real quotient is not
an integer, the problem is more complex. Do we take the floor or the ceiling
or round according to some particular formula (and there are several to
choose from)? I think we are generally agreed that we either take the floor
(which is also the zero'd) or that we round somehow.
It is only we start to consider negative dividends and or negative
divisors that things really go to hell. What does it even MEAN to divide
negative numbers? I don't know. I can go back to accounting analogies and
consider a negative amount to be money I owe and a positive number to be
money I have. Consider 5 partners who owe a thousand dollars. Each
partner's share would be -1000 5 / so I can wrap my mind around division
involving a negative dividend. Suppose there were only 3 partners. -1000 3
/ now we need /MOD fer sure. Is each one's share -333 with a -1 left
over? Or, is each one's share -334 with a +2 left over? I think we are in
the realm of philosophical questions here. As an accountant I'd say, "cough
up $333.33 each and I'll pay the extra penny!" (Accountants are happy to
write off many dollars to make things come out even, a mere penny would be
completely inconsequential.) So, I can see dividing a positive or a negative
number by a positive number, but have not been able to fully wrap my mind
around the idea of dividing by a negative number. What does it MEAN? (It
probably means nothing unless you need to do it for a specific purpose, at
which point you know what it means.)
Many months ago I suggested that flooring negative quotients ( -1000 3 /
--> -334 ) didn't feel right. It didn't correspond to my "grade school"
understanding and every day familiarity. I suggested a solution: treat
negative numbers like we (and I use "we" loosely!) treat square roots of
negative numbers. We handle these by factoring out that troublesome -1. We
find its square root separately (and by definition call it "i") and then are
left with the familiar problem of finding a square root of a positive number.
I liked (and still like) the idea of factoring out the -1s from the
dividend and divisor so that we are doing division with positive numbers
(where there is no particular controversy). Thus, -1000/3 would be treated
as (-1)( 1000/3) and -1000/-3 would be (-1)(-1)(1000/3) So, we really
only need division of positive numbers by positive numbers. (I'm not saying
this solves any problems - just that it is a comforting way for me to look at
it.)
Remember, when it comes to floored vs zero'd, there is no difference at
all for positive numbers and no difference at all when the real quotient is
an integer. It only matters when one or both of the operands is negative,
and then only if there is a remainder.
In working over some higher precision division words, I was prepared to
try flooring. Not because I think it is superior, but because Robert Berkey
thinks it is superior (I think) and because he understands it better than I
do. However, as I looked it over more & more, I stayed dissatisfied with
having -1000 3 / give -334 with a +2 remainder. I think my applications
involving negative numbers are much more likely to concern negative dollars
or positive dollars divided by a positive number. In such a case, I think it
is unfair discrimination (I fully support accurate, just discrimination) to
treat the numbers on one side of a balance sheet as different from those on
the other side. So, I want -1000 3 / to give -333 with a -1 left to be dealt
with and 1000 3 / to give +333 with a +1 left to be dealt with.
I hear you need floored with negative operands in order to control
stepper motors without them jerking. This makes no sense to me. Drive 'em
from a table; drive 'em always with either +1 or -1 till a feedback switch
goes true; scale the -10 -9 -8 ... -1 0 +1 +2 ... +9 +10 up to 0 1 2 3 ...
18 19 20 - so what's the problem? As always, maybe I'll learn more in the
future and see the need for floored division instead of zero'd.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/24/90)
Category 1, Topic 45 Message 36 Wed Aug 22, 1990 F.SERGEANT [Frank] at 22:37 CDT To Jan Hofland JH> First, I want to thank you for the 68hc11 assembler you JH> implemented for Jack Brown. Jack tells me that you did it not JH> ever using the chip. Well done! You're very welcome. Thanks for the encouragement. Yes, the assembler was meant as a little joke (I like good jokes, not bad jokes). He'd been asking if anyone knew of a pd 'HC11 assembler, so I whipped one up for him as a surprise. It was something I wanted anyway for my own use, as I planned to wire up an 'HC11 and thought I would need the assembler soon. Unfortunately, I STILL haven't got to the 'HC11 project. I was expecting error reports, as not using it, I didn't feel like testing it exhaustively. I then planned to fix any problems, but Jack fixed them himself! I didn't mean to put him to that much work, just the work of noting errors. Digital hardware designer, huh? What sort of things do you work on? That area is of great interest to me. Maybe I'm an anti digital hardware designer (digital anti-hardware designer?) as I find one of the most beautiful things in the world to be eliminating/replacing the hardware with software. Of course, it all depends on hardware in the end. Say, is that simple Forth you want to write destined for any particular uP? If it just happens to be for an 'HC11 (or any of its subsets, such as '00 or '01 or maybe '05) then you already HAVE the assembler for it and you already HAVE a metacompiling Forth (Pygmy). The 'HC11 assembler as I originally posted it was all set up to run under Pygmy, so refer to that, but incorporate Jack's corrections, but not his changes for a different Forth. Then, it should be a simple matter to re-write all the primitives for the 'HC11 and use Pygmy to meta-(cross)-compile the new version. You won't need the editor, etc, to run it as an "umbilical" Forth (use the PC as terminal & disk server & connect to the 'HC11 board via a serial line). That's what I'm going to do when I get around to it. I've already done it with a Zilog Super-8. If you are going to try this, start by re-meta-compiling Pygmy, which I think you'll find to be very easy, to get some practice. If you plan to ROM the 'HC11 version, the trick is to declare the variables the same way the system variables are declared (eg, with CONSTANTs - see RAM in PYGMY.SCR for more details). Hopefully, v 1.3 will be ready in time to help. -- Frank ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/27/90)
Category 1, Topic 45 Message 38 Sun Aug 26, 1990 R.BERKEY [Robert] at 14:57 PDT Frank Sergeant writes, 90-08-19: > I've recently been pouring over Knuth's book and Roedy > Green's assembly listing on division and thinking about and > worrying over division. I got out and brought up most of Roedy Green's division code in the middle of last month. Just needs eighteen assembler labels, and a 43K file, with the end result a floored */ with an intermediate 64-bit result. Whew. Of course, most of his file is documentation, and the key code implements a 64-bit divided by a 32-bit UM/MOD for the 80x8n. > In working over some higher precision division words, I was > prepared to try flooring. I'm curious as to which ones. I've tried implementing a signed version of MU/MOD ( d n -- rem d ) built with truncated-to-zero division, and another version built with floored division. In each case the code at first seemed to work, but actually contained subtle bugs. > I think my applications involving negative numbers are much more > likely to concern negative dollars or positive dollars divided by > a positive number. In such a case, I think it is unfair > discrimination (I fully support accurate, just discrimination) to > treat the numbers on one side of a balance sheet as different from > those on the other side. So, I want -1000 3 / to give -333 with a > -1 left to be dealt with and 1000 3 / to give +333 with a +1 left > to be dealt with. Those "to be dealt with" remainders make a difference. (1) If they are being discarded, then we're talking about the numerals shown, i.e., unrounded truncated-to-zero quotients. (2) If the remainders are used to adjust the quotient, that's rounded-to-nearest division, and the numerals shown are temporary intermediates. (3) A report with both values, such as the split-up of the partnership, is not one I'm familiar with. Conceptually it makes sense, but how a programmer gets involved with it isn't apparent to me. > I hear you need floored with negative operands in order to > control stepper motors without them jerking. This makes no sense > to me. Drive 'em from a table; drive 'em always with either +1 > or -1 till a feedback switch goes true; scale the -10 -9 -8 ... > -1 0 +1 +2 ... +9 +10 up to 0 1 2 3 ... 18 19 20 - so what's > the problem? Yes, without having the code from application examples it is difficult to verify what the problem is. Robert ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 1, Topic 45
Message 39 Sun Sep 02, 1990
F.SERGEANT [Frank] at 11:41 CDT
Len made this comment in the Haydon guest conference:
> In every Forth I know except one, TIB is the Address of the
>terminal input buffer. In Pygmy, it is a variable that contains the
>address. That little bit of non-standardization cost me half a day's
>work. This is an example of why standards are necessary.
And, the question has come up previously as well.
I would like to think that, rather than costing Len half a day's work,
it provided him an opportunity (a laboratory, if you will) for honing his
opinions about standards.
I have always said that a quality education is expensive.
I would like to quote from the fig-FORTH GLOSSARY:
TIB --- addr U
A user variable containing the
address of the terminal input
buffer.
So, I believe Pygmy is in good company regarding its method of handling
TIB.
I hope I have not, and I believe I have not, misled anyone into thinking
that Pygmy Forth is an attempt to implement the/a "standard."
I really enjoyed Glen Haydon's remarks in the guest conference,
especially his comments about free markets.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/06/90)
Date: 08-27-90 (08:04) Number: 711 (Echo) To: FRANK SERGEANT Refer#: 707 From: JAN HOFLAND Read: NO Subj: PYGMY FORTH Status: PUBLIC MESSAGE Hi Frank, Thank you for you lengthy reply. I work on building special purpose controllers for our Dynamic Signal Analyzer product line here at Hewlett-Packard. The stuff I have worked on in the last few years are built around the Motorola processor line, both 68000 and 68020. There is usually a fair amount of RAM (the controller now uses 16 Mbytes) and then interface to special purpose busses. My current assignment involves interfacing to the SCSI bus. With respect to what processor to target my interest in rolling my own forth, the list is many. There's the hc11 and then the RTX product line and even a Motorola 56001. At this point my goal is to understand how to do it and what routines and procedures are necessary at the machine code level to support a forth system. Truthfully, at this point I am more interested in learning the underlying software routines rather than using the result for some specific purpose. I look forward to the next pygmy forth release. Regards, Jan Hofland --- ~ EZ 1.27 ~ NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/09/90)
Category 1, Topic 45
Message 41 Sat Sep 08, 1990
F.SERGEANT [Frank] at 16:52 CDT
To Jan Hofland,
Under the guise of replying about Pgymy, I'd like to ask a bulletin
boarding question(s).
With luck, I may be able to release Pygmy Forth version 1.3 within 1 to 2
weeks. The Forth part is finished, I think. There are many questions to
resolve about the documentation and what to include in the package.
Now my real question: I seem to have a mental block in dealing with
computer bulletin boards. I seem to get along well enough in GEnie now, but
I've tried logging on to the ECFB and feel very disoriented. I notice your
message had an EZ 1.27 tag and the "NET/Mail" connected with it. What is
that? How does it work? Do I understand that it is possible to log on to
BCFB (& ECFB) and somehow download all of the new messages in one fell swoop,
possibly as a ZIP or ARC file? Then, compose your replies off-line and
upload a single ZIP or ARC file next time you log on, and have the system
distribute the various messages to their proper areas? If so, could you tell
me how to do it? Thanks. -- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/21/90)
Category 1, Topic 45
Message 43 Wed Sep 19, 1990
F.SERGEANT [Frank] at 23:06 CDT
Pygmy Forth version 1.3
Here it is. I uploaded it last night, so it should be available in the
near future as file #2202 in library #12 as PYGMY13.ZIP (67K).
[See previous ForthNet note, under subject "Files on-line". -dwp]
The previous versions were put in library #4, but for variety I put this
version in the "Experimental Systems" library.
Thanks to all who made suggestions. I have acted on some and at least
thought about the others. For example, Steve Palincsar suggested it was
confusing to have the documentation in block files with a .DOC extension. I
took that one step further. I put all the source code in a single (block)
file, PYGMY.SCR. This now includes the kernel, meta-compiler, editor,
assembler, *Starting Forth* examples, and miscellaneous source code. I put
all the documentation into the single (text) file, PYGMY.TXT. The file
PYGMY.COM, naturally, is the executable file. Pygmy Forth with kernel &
editor & assembler now fits in a 14K file, however PYGMY.COM is 15,368 bytes
long. The extra is due to the inclusion of SEE, >SCR, >PRN, and words to
print source code &/or shadows, 3 or 6 screens per page. That was done to
make it easier (as suggested by Chris Waters) for the new recipient of Pygmy
to print out the source code. I also have attempted to make CONDENSED
default to put an Epson printer into 17 cpi mode (and have also included the
code as before for Okidata printers). I have included YOURFILE.SCR as an
empty block file 8 screens long so the person new to Pygmy can get started
right away with a place to put the code he writes, without worrying about how
to MAKE or OPEN a file.
The major changes have to do with file handling. New file read and
write words let you read arbitrary numbers of bytes either directly or
sequentially. All file accesses are via a unit# or via block numbers (which
ultimately find the file based on its unit#). This has smoothed out and
regularized and added greater flexibility, in my opinion. The editor (and
BLOCK) will no longer let you access past the end of file. Holes (spread
open the file to insert blank blocks), SETTLE (let the "heavy" screens settle
to the bottom), & CHOP (delete the trailing blank screens at the end of a
file) make maintenance of block files considerably easier.
The question I might have on my mind, if I had a previous version of
Pygmy, is whether I should bother downloading version 1.3. I think it
depends on what you want to do with it. If you downloaded it as a curiosity
to look at briefly and set aside, I'd say no, don't bother. You've already
seen the main ideas. If you downloaded it and wanted to use it, but it
wasn't quite polished enough, I'd say 1.3 is worth a look. If you are
actually using a previous version, I'd say you definitely should get 1.3. If
you are looking for a Forth for the IBM/clone world, and think F-PC is too
large for you, I think you could be happy with Pygmy Forth. It is easy to
download and easy to change so it does things your way if you don't like how
I did it.
I might be surprised, but I think 1.3 can stand as the final version. I
didn't feel that way about the previous versions. I think I've cleaned up
all the little things that had to be cleaned up.
I have asked myself whether there is any point to Pygmy. There
certainly was for me personally. I've had fun with it. I've enjoyed the
correspondence connected with it. It is the Forth I use for everything. It
has grown large enough to be comfortable, and thereby lost the attribute of
being tiny (I mean, 14K is pretty big for a Forth, don't you think?). I
think I could have been happy using plain BBL (not Abundance) or Guy Kelly's
Forth. Compared to F83, they and Pygmy have more comfortable editors. I
think Pygmy's file handling suits me better. I think Pygmy's meta-
compilation is the simplest. EForth is interesting and more easily portable,
but is pretty slow, without the re-writing that would make it less portable.
It and Beta Forth (the Russian Forth) and Zen (I think) aren't really usable
(I think) without an editor and assembler. F83 is certainly usable and
deserves a lot of credit. Abundance and F-PC are in an entirely different
category, and not really usable by me at all, at this time. So, all in all, I
think Pygmy has a good mix of speed, small size, file handling, and comfort.
At least it is a mix that seems to suit me better than the non-commercial
alternatives that I'm aware of. One advantage for me is that Pygmy is mine.
For you it is just another Forth competing for your time & attention &
download dollar. It is hard for me to look at it objectively!
I don't know why, but I have the urge for people to use it and enjoy it.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/21/90)
Category 1, Topic 45
Message 44 Wed Sep 19, 1990
F.SERGEANT [Frank] at 23:07 CDT
Forth vs Assembly Language
There has been a discussion of whether Forth can better be popularized
by distributing it as an assembly program or as a Forth program. Ting
supports the former. Bill Ragsdale suggested that it makes no difference up
to a certain size. figForth was distributed as an assembly listing, but was
also distributed as a Forth listing. I think this has sometimes been
forgotten. I have a strong preference to Forth being written in Forth. As
an argument for this, I suggest downloading EForth (Ting & Muench) and
looking over the assembler listing for it and then the Forth listing of it
(both are included). I think the Forth listing is far clearer. There might
have been a stronger argument in favor of the assembler listing in the dark
ages, when only paper was distributed. That way you could enter the hex
codes by hand, through a monitor, then patch the I/O routines, and finally
get something running. When a disk or modem squeals can be distributed, a
running Forth executable file can be distributed at the same time (which can
re-gen itself from its source written in Forth), thus obviating the need for
the assembly listing.
This still leaves the question of whether it is more appealing to
newcomers to have Forth written in Forth or in assembler. If they have no
interest in Forth I don't see how having Forth written in assembler is going
to create that interest. If they do have an interest in Forth, I think
they'd be more interested in seeing Forth written in itself. Of course, the
EForth and figForth approach of giving them both would seem to satisfy
everyone.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpheron@mars.jpl.nasa.gov (Vance Heron) (09/22/90)
In article <1778.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >Category 1, Topic 45 >Message 44 Wed Sep 19, 1990 >F.SERGEANT [Frank] at 23:07 CDT > >Forth vs Assembly Language > > > This still leaves the question of whether it is more appealing to >newcomers to have Forth written in Forth or in assembler. If they have no >interest in Forth I don't see how having Forth written in assembler is going >to create that interest. If they do have an interest in Forth, I think >they'd be more interested in seeing Forth written in itself. Of course, the >EForth and figForth approach of giving them both would seem to satisfy >everyone. > Let me take a stab at answering this - I am slightly more than a novice in forth, but I have written some applications in it including a Control Program for an Infrared Camera currently in use on the Mt Palomar 200" telescope and other applications to test Millitary Communications Equipment (Air Farce) Anyway - I'm not sure a novice really cares about either, but after working/playing with it for a while I got interested in "rolling my own" and was disappointed that none of the smaller forths I got included source code that would enable one to start from scratch (i.e. assembly). Because the interpreter is such an integral part of forth, it seems much less "satisfying" to write forth in forth (as opposed to writing a C compiler in C). I had the fortune to be able to do just that in my college days, but the resulting code was MACHINE LANGUAGE - I could use C on one machine to write a compler that would run on a different one - once I had cross compiled the compiler - I would have a native compiler on the new machine (I didn't do all this, but is seemed feasable ?!?) Given a Forth system like PYGMY (I really love it - thank you Frank) how could I port it to a 68000 box ??? How did Frank get his 1st interpreter up so he could interpret the rest ?? Given my almost novice status I probably am missing something - but I think assembly would help a larger group of programmers - if one is not interested in Forth, they wont bother to look for source in either language, and if one is interested in "building" a new forth, the ability to start from scratch will probably be wanted/needed. Just my $0.02 Vance heron@mars.jpl.nasa.gov
ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) (09/22/90)
> >Because the interpreter is such an integral part of forth, it >seems much less "satisfying" to write forth in forth (as opposed >to writing a C compiler in C). When I am asked about the best way to learn Forth (which I'm not asked often), I reply that the best way is to roll your own. It is amazingly easy given that the rollee has some rudimentary knowledge of common computer science techniques like linked lists, string (token) parsing, stacks, and fundamental operating system interfaces. I was able to do it fresh out of college with a B.S. in Astronomy minoring in Computer Science. The highest hurdle is grasping the workings of the inner interpreter; and after that, the outer interpreter. The interpreter operation just isn't something taught in school (at least in my school). It isn't hard, just different. Whether the interpreters are learned from assembly or C isn't important. It's knowing them, and by induction, how to manipulate them, that all of Forth falls into place. From there, the operations of BRANCH and ?BRANCH, (DO) and (LOOP), etc., is trivial. Some systems de-emphasize the progammers involvement with the inner workings of Forth. Fine. Compared to the complexity of other software I have to contend with daily, Forth is trivial. Learning it on my own gave me the insights I have applied to systems ranging from IBM System/370 mainframes, to VAXen, to Sun workstations, to PCs. When it comes right down to it, they all work the same, only different. Writing a Forth for the Commodore 64 (and then the Apple //), that was source-compatible with IBM PCs, CP/M machines, and VAXen, proved that to me. Enough philosophy. -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM Internet: zmleb@scfvm.gsfc.nasa.gov -- "Between an idea and implementation, is software." -- Curse from Hubble -- Space Telescope engineer.
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/25/90)
Category 1, Topic 45 Message 48 Sun Sep 23, 1990 JETHOMAS at 21:41 CDT I liked your 1.2 Pygmy a lot, it's simple enough to grasp pretty easily. I was glad to see the 1.3 version, which duplicated many of the changes I made and more besides. The method for opening files seems unnecessarily tedious, but it's easy to open a file once and then save the system with the file open, so it doesn't have to be done all that often. I probably won't do anything about it. I've found a really minor bug -- you didn't change Robert Berkey's DO LOOP code to match your new FOR NEXT, so : TEST 10 0 DO I . LOOP ; will print out: TEST 1 2 3 4 5 6 7 8 9 ok This is easy to fix. : (DO) ( limit index - for-index ;R ip - index-offset ip ) ( OVER 1- POP SWAP PUSH PUSH - 1- ; ) OVER 1- POP SWAP PUSH PUSH - ; : >R COMPILE PUSH ; : R> COMPILE POP ; I've had a lot of fun with Pygmy. Thanks for making it! ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/25/90)
Category 1, Topic 45
Message 50 Mon Sep 24, 1990
F.SERGEANT [Frank] at 20:00 CDT
Pygmy Forth Version 1.3 Beta Test Standings:
JETHOMAS is in the lead with 2 reported bugs and 1 fix. Who will be
next?
Bug 1: DO LOOP in the Starting Forth section wasn't changed to match the
new FOR NEXT. The fix is to remove the 1- at the end of the definition of
(DO) on screen 171 of PYGMY.SCR.
Bug 2: In order for the program to open your files automatically, you
must have OPEN'd the files before creating the new .COM file. This is a bug.
All you should need to do is install the file with UNIT. The file should not
need to be open when you do SAVE to create the new .COM file. The quick fix
is to add CLOSE-FILES just prior to OPEN-FILES in the definition of
(BOOT on screen 79 of PYGMY.SCR. Then re-meta-compile. (Or just do 79
LOAD SAVE PYGMYNEW.COM ). This fix doesn't get at the heart of the matter.
I think there still must be an underlying bug, but I haven't found it yet.
I'll let you know as soon as I do.
I hope to find the cause of 2 above before uploading a corrected file in
the library to replace #2202. If you pass along copies of #2202, please make
the above two corrections.
To JETHOMAS
Thanks!
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/06/90)
Category 1, Topic 45
Message 51 Thu Oct 04, 1990
F.SERGEANT [Frank] at 22:57 CDT
Pygmy Forth 1.3 Corrections October 4, 1990
[I'm posting this for those that want to make the changes themselves.
When these files are available on SIMTEL20, I'll post another note. -dwp]
Three errors have now come to light (I found the 3rd one). I am re-
uploading the Pygmy Forth package to correct these: PYGMY13.ZIP. I am also
uploading a copy of this message as PYG13FIX.ZIP. If you have previously
downloaded the September 17, 1990 version (GEnie file #2202) there is no need
to download this corrected PYGMY13.ZIP. Just edit in the following changes:
Errors corrected since version 1.3 was originally released:
1. The definition of (DO) on screen 171 was : (DO) OVER 1- POP
SWAP PUSH PUSH - 1- ; should be : (DO) OVER 1- POP SWAP PUSH PUSH - ;
this adjusts for the change to FOR NEXT.
2. In definition of (BOOT on screen 79, the word OPEN-FILES should be
preceded by the word CLOSE-FILES. This eliminates the problem of needing all
the files open at the time you save an executable image (e.g. SAVE
PYGMY3.COM).
3. Definition of IN, on screen 115 was EC M9 IN, should be
E4 M9 IN,
Note: I do not see why the #2 fix is needed. This makes me suspect
there may be another, underlying, bug. If and when I discover it I'll post
the details.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/12/90)
Category 1, Topic 45
Message 53 Thu Oct 11, 1990
JETHOMAS at 03:54 CDT
> I haven't understood your point, yet, in setting bit 8 instead >of bit
7, for (ONEKEY. If you wanted to set another bit, why not >bit 15, then the
16-bit number could be checked with a 0<. But, I >don't see why you want to
distinguish between the two types of keys. >The key pressed either matches a
value in the list of OF statments >or IF statements or equivalent lists, or it
is invalid for that >operation. Maybe there are some normal keystrokes (single
byte from >DOS) that have bit 7 set, and so they become indistinguishable
Yes, that's exactly it. There are normal keystrokes that match. I settled
for setting bits 7 AND 8, using bit 8 to get to SPCL in the editor, and doing
255 AND to strip out any extra bits. By setting bit 7 too, I delayed
rewriting the SPCL' jump table in the editor. That was the only place PYGMY
used special characters. Using bit 15 would work slightly better. I have a
prejudice for a straightforward 9-bit keyboard code, but I don't really see
that it would matter. Alt-keys are coded in increasing order from left to
right across the keyboard, apparently independent of what the key stands for.
It probably wouldn't be much advantage to code the keys as one long jump table
instead of 2 shorter ones, if it ever came to doing something like that.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/04/90)
Category 1, Topic 45
Message 54 Sat Nov 03, 1990
F.SERGEANT [Frank] at 14:28 CST
Screen Attributes in Pygmy
I'll explain how to change the foreground and background colors. It is
all controlled by the variable ATTR (which stands for "attribute"). The most
significant nibble controls the background color and the next-to-most
significant nibble controls the foreground color. The 2 least significant
nibbles (the least significant byte) should be set to zero.
Do HEX ATTR @ U. to see what colors are currently set.
On my color system I get 7100 where the 7 is a light background and the
1 is a blue foreground. For the monochrome system, I believe the attribute
would be hex 700 where the (unseen) leading zero is the background and the
7 is the foreground.
The next step is to try different values until you get ones you like,
for example
HEX
1700 ATTR !
5400 ATTR !
3200 ATTR ! when you find the combination you like best, you can
either type it in each time you bring up Pygmy, or you can SAVE
NEWPYGMY.COM after making the change once, or you can search across screens
in the editor for ATTR to see where it is initialized to either $7100 or
$0700 and change it to your values and regen (meta-compile) Pygmy.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/04/90)
Category 1, Topic 45
Message 55 Sat Nov 03, 1990
F.SERGEANT [Frank] at 14:29 CST
JB>I'm having a little problem with PYGMY Forth. What I want to do is
JB>simple. I want to read a binary file, alter the filepointer to skip
JB>some header bytes, and copy the rest of the file to a diskfile or
Here is how I would approach it. Suppose I just want to read the file
PYGMY.TXT into a buffer.
NAMEZ: PYGMY.TXT ( define the name)
3000 PYGMY.TXT 6 UNIT 6 OPEN ( install & open the file)
6 >BOF ( move to the beginning of file)
100 6 +POSITION ( skip past the 1st 100 bytes)
PAD 200 6 FILE-READ ( read the next 200 bytes into a buffer)
HEX PAD 50 DU ( DUmp the buffer to the screen )
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/05/90)
Category 1, Topic 45 Message 56 Sun Nov 04, 1990 J.BLACK13 [John Black] at 09:00 EST Reference message # 55 Frank, I appreciate the reply on using PYGMY Forth to read binary files. Your code works; mine didn't though I'm not sure why. Lifes too short to figure out everything; I'll just use yours. The next problem I'm working on is some way to issue DOS commands from Forth. I need to to some file renaming, deleting, unzipping, etc. I'd like to be able to do it from Forth without resorting to external batch files. Know of any PYGMY routines that have been developed? Thanks JEB ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/07/91)
Category 1, Topic 45 Message 58 Sun Jan 06, 1991 J.BLACK13 [John Black] at 14:18 EST Has anyone developed good SCAN, SKIP, or PARSE WORDS for Pygmy Forth? Or a Pygmy Forth way to get argv, and argc values from the DOS command line? I've looked at some code versions of these words for Forth 83, but ignorance of 8086 assembly language makes the code inscrutable to me. I like Pygmy Forth because its thin rather than fat, BUT I'd like to easily be able to add selected "fat" as I need it. Wish more selected "fat" words were available for Pygmy. Thin is absolutely essential for writing utilities for others to use. 128K or so taken up by a Forth system to do something needed, but basically simple, makes Forth look cumbersome and comical. BTW, Pygmy is nicely done and mostly user friendly -- I'd recommend it as a good learner system. The documentation provided with it is very useful. It, as all other Forths, does it own thing on some words. I agree with most of them. Using FOR and NEXT and POP and PUSH rather than the more awkward constructions they replace is nice! Forth's strength is also its biggest impediment. Its ability to change itself to meet the user's needs results in a multiplicity of versions that preclude easy use of building blocks developed on other systems. That will ensure that only dedicated fans of the language will pursue it. A few people really enjoy making the bricks and cutting the lumber when they're building a house. Most just don't have the time for it. I'm a fan of the language --but even I'd like a really nice set of tools so I could get more out the door. ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/10/91)
Category 1, Topic 45 Message 59 Wed Jan 09, 1991 F.SERGEANT [Frank] at 02:54 CST To Tom Schotland I think I saw some messages from you on both GEnie (via RCFB) & the CC bbs about Forth & the 8051. I composed a reply and almost posted it, but thought better of it. I was afraid I might talk myself into porting Pygmy Forth to the 8051. But, of course, I can't resist replying to a message that names me! Pygmy Forth is customized for PCs & clones (PC/MS-DOS 8088/80x8x machines). It is available for downloading everywhere (I suppose). Look for version 1.3. The file name on GEnie is PYGMY13.ZIP. I think of it as a small, but complete Forth. It allows up to 15 (or perhaps many more) DOS files open at one time. Their origins are at different BLOCK numbers, which makes it easy to copy to and from the different files, etc. You can specify a set of files to be opened automatically. It can read and write any format files, but source code loading is done from BLOCK files. It has some neat features from cmFORTH such as the COMPILER vocabulary. All immediate words are in that vocabulary. Thus there is no word IMMEDIATE. It makes it easy to have, for example, two versions of the word ." one is in FORTH and executes outside of colon definitions and the other has the same name but is in COMPILER and compiles the string for execution at run-time. This eliminates the need for abominations such as .(. It is a COMPLETE Forth. No, I don't mean it has everything that could be present in a Forth; I mean you can use it when it arrives. It comes with full source code, meta-compiler, editor, and assembler. Modifying it and meta-compiling a new version is especially simple. This lets you change the aspects of it that you disagree with me about. For example, it uses the sensible approach of having ( u) FOR ... NEXT perform the loop u times, rather than u+1 times. 0 FOR ... NEXT performs the loop zero times. But, anyone who wants the u+1 and 0+1 version can make the changes and meta- compile it his way. No. It does not run on the 8051. I have, however, made a version to run out of ROM for a Zilog Super-8. I expect one day to port it to various other processors. When? Who knows. There's no point in waiting on me. What do you want in the way of a Forth for the 8051? What would you do with it? What amounts of ROM & RAM would you have available? Talk to it from a PC? Etc? -- Frank ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/10/91)
Category 1, Topic 45
Message 60 Wed Jan 09, 1991
F.SERGEANT [Frank] at 02:54 CST
JB>Has anyone developed good SCAN, SKIP ... for Pygmy Forth?
Assuming a string AAAABBBB at address 100, I have a SCAN that will hunt for
a specific character as in ( 100 8) 'A SCAN ( 100 8) or ( 100 8) 'B SCAN (
104 4) or ( 100 8) 'C SCAN ( 108 0). And a SKIP that will eat beginning
delimiters. ( 100 8) 'A SKIP ( 104 4) or ( 100 8) 'B ( 100 8). Are those
what you want? If so:
CODE SCAN ( a # char - a #)
DS AX MOV, AX ES MOV, BX AX MOV, CX POP, DI POP,
REPNZ, AL SCAS, 0=, IF, DI DEC, CX INC, THEN,
DI PUSH, CX BX MOV, NXT, END-CODE
CODE SKIP ( a # char - a #)
DS AX MOV, AX ES MOV, BX AX MOV, CX POP, DI POP,
REPZ, AL SCAS, 0=, NOT, IF, DI DEC, CX INC, THEN,
DI PUSH, CX BX MOV, NXT, END-CODE
At least I hope that's what they do. As for the command line, it is sitting
in memory at address $80 in the same segment Pygmy is running out of. To see
it, do
HEX 80 DUMP ( DUMP .... DUMP)
Byte $80 holds the number of characters and those characters begin at byte
$81.
Thanks for your comments.
-- Frank
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/13/91)
Date: 01-09-91 (19:08) Number: 823 of 834 To: J.BLACK13 [JOHN BLACK] Refer#: 786 From: STEVE PALINCSAR Read: NO Subj: PYGMY FORTH Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) -> available for Pygmy. Thin is absolutely essential for writing -> utilities for others to use. 128K or so taken up by a Forth system to -> do something needed, but basically simple, makes Forth look -> cumbersome and comical. Hardly true. A fully-featured forth like HS/Forth or UR/Forth is perfectly capable of creating a very reasonably sized EXE file. I use HS/Forth to create 'utilities for others to use' and generally end up with a 30K or thereabouts EXE file. PCRelay:DCINFO -> #16 MetroLink (tm) International Network 4.10 DC Info Exchange MetroLink International Hub <<<>>> ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/13/91)
Category 1, Topic 45 Message 62 Sat Jan 12, 1991 J.BLACK13 [John Black] at 19:47 EST Frank, thanks a lot for the SCAN and SKIP words for Pygmy Forth. I'm about to finish up a simple program that converts a picture bitmap dump from a PCL Laserjet format to an encapsulated Postscript format. The file conversion is fairly straight forward. I'm close to getting it running as a command line utility. I could have done it in C, but it was a lot more interesting doing it in Forth. BTW, how difficult is it to make Pygmy ROMable? JEB ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/13/91)
Category 1, Topic 45 Message 63 Sat Jan 12, 1991 J.BLACK13 [John Black] at 20:45 EST How do you end up with really small file sizes for your exe files? I may be overlooking something. The other related issue is running space. Most of the Forths I've seen expand into at least 128K in memory when you run them. Thats a lot of memory for something simple--particularly when its mostly unused vocabulary space. On the other hand, I've seen pretty complete Forths on very small computers in a very small memory space. JEB ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/16/91)
Category 1, Topic 45 Message 64 Mon Jan 14, 1991 F.SERGEANT [Frank] at 02:15 CST Oops - Regarding my recent posting of CODE words for SKIP & SCAN: After recently re-reading some comments ROEDY GREEN posted in December '89 I am inclined to rename SKIP to -LEADING= and rename SCAN to -LEADING<>. -LEADING would eat leading spaces (just as -TRAILING eats trailing spaces). For many years I have referred to bypassing spaces (or whatever) as "eating spaces" but until now I hadn't considered using "eat" in the name of the Forth word that does it. I'm not inclined to use EAT-TRAILING-SPACES and EAT- LEADING-SPACES and EAT-LEADING-CHARACTERS-THAT-ARE-NOT-EQUAL, etc but perhaps I'll start pronouncing the hyphen in -TRAILING and -LEADING as "eat" (thus - TRAILING would be pronounced "eat trailing") and have the best of both worlds. -- Frank ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/16/91)
Category 1, Topic 45 Message 65 Mon Jan 14, 1991 F.SERGEANT [Frank] at 02:16 CST JEB> BTW, how difficult is it to make Pygmy ROMable? Nothin' to it. All you have to do is go through the source code for Pygmy and make sure that any time it tries to change memory, that that memory is RAM not ROM. The above is the key but might make it sound harder (or easier) than it is. Browse through the source code (mainly screens 0 - 80 of PYGMY.SCR). Look for the word RAM. Note how CONSTANTs and system constants work. You'll need to initialize RAM to point to actual ram. That will take care of system variables (which are defined via CONSTANT). You'll have to change VARIABLE so it uses CONSTANT and RAM for any of the variables that are defined in ROM. You'll have to see that H (dictionary pointer) points to actual RAM. You'll have to see that your ROM and RAM are in the same 64K segment (this might be the hardest to do on a PC). Watch out for DEFER and IS and make sure all variables are initialized correctly. Those are the main things that come to mind. As you browse through the source you might see other things that need attention. Are you planning to run it on a PC? If not, getting the ROM & RAM in the same segment should be easy. But then, I'd think you'd not want to have DOS either. In that case look over any DOS calls and be sure they get changed over to BIOS calls (assuming you'll still have the BIOS ROM). On the other hand, you might have been talking about putting Pygmy on another processor, etc, which is pretty easy, especially if you can use a PC (with Pygmy on it) as the terminal and file server. If you plan to run it on a PC from ROM, I must ask WHY? If you'll still have BIOS & DOS and still want Pygmy in ROM, the simplest thing to do would be to put the unROMable version of Pygmy in ROM but change the very beginning boot up code (on scr 17) to copy itself, byte by byte, into RAM and then do a long jump to the RAM copy. This way all the problems of making it ROMable disappear. I hope the above gives you the general idea. If you'll give me more details on exactly what you want to accomplish I might be able to refine my advice somewhat. JEB> How do you end up with really small file sizes for your exe JEB> files? I may be overlooking something. The other related issue JEB> is running space. I don't bother. I just run everything out of Pygmy. Pygmy is not set up to make headerless definitions (which would save some space). With the editor and assembler Pygmy only takes up about 14K of disk space. The kernel by itself about 8K. Using the meta-compiler you should be able to generate a system that has only the words in it that you want, leaving out the editor, assembler, unneeded file words, SEE, .S, anything you didn't need. This would still let you *use* the assembler, etc. at meta-compile time - it just wouldn't be present in the target image you are building. I imagine this could get your utilites down to a fairly small (disk) file. The related question is how much RAM does it take up at run-time. All programs run under DOS initially take up ALL the available ram! All programs! To take up less RAM they have to explicitly release some. Why do you care how much it takes up, unless you plan to start another "process" from within Pygmy, or unless you make it a TSR, or unless you already have so many TSRs loaded that you have less than 64K of RAM available? Pygmy always occupies 64K of RAM. (If the optional HASH dictionary lookup method is used, it takes up 128K.) You can change down to 10K, 12K, 20K, whatever by initializing the stacks, disk buffers, TIB to lower memory and then doing a DOS call to release all the memory above them. I hope I've answered what you wanted to know; if not, ask again with some more specifics. -- Frank ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/28/91)
Category 1, Topic 45
Message 67 Sat Jan 26, 1991
F.SERGEANT [Frank] at 09:29 CST
Here are the corrected definitions of SKIP & SCAN. Other than the names,
the only changes are the 1 #, AL OR, and the AX AX SUB, whose purposes are
to set the zero flag prior to the rep scas instructions.
CODE -LEADING<> ( a # char - a #)
( eat leading non-delimiters)
1 #, AL OR, ( force zero flg false)
DS AX MOV, AX ES MOV, BX AX MOV, CX POP, DI POP,
REPNZ, AL SCAS, 0=, IF, DI DEC, CX INC, THEN,
DI PUSH, CX BX MOV, NXT, END-CODE
CODE -LEADING= ( a # char - a #)
( eat leading delimiters)
AX AX SUB, ( force zero flg true)
DS AX MOV, AX ES MOV, BX AX MOV, CX POP, DI POP,
REPZ, AL SCAS, 0=, NOT, IF, DI DEC, CX INC, THEN,
DI PUSH, CX BX MOV, NXT, END-CODE
: -LEADING ( a # - a #) ( eat leading spaces) 32 -LEADING= ;
-- Frank
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/18/91)
Category 1, Topic 45 Message 68 Sun Feb 17, 1991 C.CLARK21 at 19:23 EST I am working on a program for my Forth Construction course and I ran into a problem. It is a fairly simple program -- convert farenheit to celcius using scaled integers instead of floating point numbers. I understand how to do the program except for one part. I can't get the output format routine to work correctly. We are using the book _Starting_Forth_ by Leo Brodie for the course and I was trying to use a routine similar to the one on page 111: : #.#### DUP ABS 0 <# # # # # 46 HOLD # ROT SIGN #> TYPE SPACE; I am using PYGMY v 1.2 to do it. I already eliminated the 'TYPE' because pygmy doesn't require it. I can make it work with unsigned numbers by removeing the DUP, ABS, ROT, and SIGN but cannont seem to make it work with signed numbers. Does anyone have any ideas? I am really stuck (and the program is due tomorrow!). Thanks, Craig [I ported this because of general interest value, not because of the (now outdated) plea at the end. -dwp] ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/22/91)
Category 1, Topic 45
Message 69 Thu Feb 21, 1991
F.SERGEANT [Frank] at 01:19 CST
Craig,
.
Damn! I'm disappointed I didn't get your message in time to help with the
class assignment. Any way, here is the solution in Pygmy Forth version 1.3.
It should work in 1.2.
.
: #.#### ( n -) ( print a signed 16-bit number )
DUP PUSH ( save sign)
ABS <# # # # # 46 HOLD ( decimal point) #
POP SIGN #> ;
.
And here is how you might have approached solving it: Search across
screens in the file PYGMY.SCR for something like <# or SIGN until you
found the source code for number output. Look at the words that use SIGN to
see how they do it. If my 1.3 version doesn't quite work in 1.2 you may
still get a chance to try out this paragraph.
.
I'd love to hear details of your class and how the assignment worked out.
I hope you solved. In the future there is always the possibility of ugly
brute force. Never rule it out!
.
( quick untested example of ugly brute force)
.
: #.####
DUP 0< IF ." -" THEN
ABS 10000 U/MOD ( r q) 1 .R ." ."
1000 U/MOD 1 .R
100 U/MOD 1 .R
10 U/MOD 1 .R
1 .R ;
.
-- Frank
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpkebang@cs.mcgill.ca (K. LIN) (02/28/91)
Header says all
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 1, Topic 45 Message 73 Sat Mar 02, 1991 F.SERGEANT [Frank] at 17:12 CST K.LIN from Montreal asks "PYGMY Forth -- where can I find it?" . Join GEnie and download file PYGMY13.ZIP. Or, FIG (408) 277-0668 can mail you a diskette. Or, many other bulletin boards and some shareware houses carry it. Look for version 1.3. The individual files should have a date and time of 10-04-90 1:31a. -- Frank [You can also get it from WSMR-SIMTEL20.ARMY.MIL in PD1:<MSDOS.FORTH> or WUARCHIVE.WUSTL.EDU in /mirrors/msdos/forth, or if you have email only access to the net, drop me a note and I can email it to you. --Doug] ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 1, Topic 45 Message 74 Sat Mar 02, 1991 F.SERGEANT [Frank] at 17:13 CST To Matthew Burke Re metacompiling in Pygmy . > I just downloaded PYGMY 1.3 from wuarchive.wustl.edu ... I have not been > able to get the metacompiler to work and was wodering if anyone else > had. . . The first question is whether you are doing something wrong or whether the file(s) you got from wuarchive.wustl.edu are bad. Here is the DOS directory listing info for the two key files for Pygmy 1.3: . PYGMY.COM 15426 10-04-90 1:31a PYGMY.SCR 187392 10-04-90 1:31a . If you don't get the same info, then you may not have the current files. If you do, then probably you do have the correct files. If you have the September (1:30a) files, they should still work. . I just tried out metacompilation on my copies of the above files and it worked fine. Here's what I did, running from a floppy on drive B: . B:>PYGMY 1 LOAD BYE . It worked fine, creating the kernel file H1.COM (whose name you can change on screen 1 of PYGMY.SCR). Then to verify it, I used the kernel file to build the rest of the Pygmy system by typing . B:>H1 83 LOAD BYE . It worked fine, extending the kernel to various degrees and saving the results as H2.COM, H3.COM, and H4.COM. Then from DOS I compared PYGMY.COM to H4.COM and they matched exactly. . So, please try the meta-compilation exactly as I demonstrated above, from the original files (where you have made no changes at all to PYGMY.SCR) and see what happens. If it doesn't work, please report exactly what you did and exactly what did happen, and maybe I can figure out what is going wrong. . You mentioned that TCREATE was missing. Missing from *where*? I found it on screen 7 of PYGMY.SCR. Get into Pygmy and type 1 EDIT to get into the editor. Then press the F3 key (for setting up a search string) and type TCREATE followed by the enter key. This will cause the editor to search screen 1 for "TCREATE" and it won't find it. Now press the F10 key and the editor will search across screens until it comes to TCREATE or until it comes to the end of the last screen in PYGMY.SCR. . When in doubt, exit to DOS (with BYE) and bring up a fresh copy of PYGMY.COM. When further in doubt, do a Ctrl-Alt-Del reboot of your computer. To eliminate all doubt, do a "master reset." That is, turn off power to the computer with the Big Red Switch, wait a few minutes, and turn the computer on again. Try to go back to copies of the original files you downloaded. . One caution, after you have meta-compiled or started meta-compiling, you shouldn't try to meta-compile *again* without exiting to DOS and reloading PYGMY.COM (why? you may not care why, but it is because you have already redefined colon, etc and when you try to redefine them a second time things won't work). . Now, here is a general complaint I'd like to lodge against those who are guilty of it. This applies only mildly to Matthew. He says "I have not been able to get the metacompiler to work." Now, that's not bad. After all, he *did* say it was Pygmy Forth and he *did* say it was version 1.3 and he *did* say where he got it. But he didn't say *what* he did specifically in his attempt to get it to work and he didn't say *what* happened in response. Could such info have helped me pin-point the problem? Possibly. Someone else posted a sample of code he couldn't get to work (it had nothing to do with Pygmy) and didn't even bother to say what Forth he was using or what type of computer. (In spite of that Dennis Ruffer was kind enough to answer him.) My point here is that requesters of help should give as much info as possible. This will increase their chance of getting appropriate answers. . Matthew, if you are in doubt about whether you have the correct files, you could copy them to a floppy and send the to me and I'll compare them to the masters. Or, you could ZIP them with PKZIP v1.1 and see what CRCs you get. I get AA74E3CD for PYGMY.SCR and EBBCB497 for PYGMY.COM. . Feel free to write with more info or questions as I would very much like to help you work this out. . -- Frank ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
kebang@cs.mcgill.ca (K. LIN) (03/08/91)
In article <2436.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >Category 1, Topic 45 >Message 73 Sat Mar 02, 1991 >F.SERGEANT [Frank] at 17:12 CST > > K.LIN from Montreal asks "PYGMY Forth -- where can I find it?" > . ... detail deleted > -- Frank > ...(Message from Doug) I downloaded a copy from WUARCHIVE.WUSTL.EDU. Thank you very much! K.LIN
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/12/91)
Category 1, Topic 45 Message 77 Mon Mar 11, 1991 F.SERGEANT [Frank] at 02:14 CST This is a reply to Henry Vinerts's open letter (uploaded as file PYGMYLTR.TXT in library 7) to me. . Thanks for your kind words. It sounds like you are successfully on the path toward learning Forth. I didn't see anything in your letter that I was sure was a direct question to me. If I over looked any such questions, please post them again. If you are attending the SVFIG meetings, I think you have unlimited expertise available to assist you. . In addition, questions etc. may always be posted in this topic. If you feel a question is too stupid to post publicly you can always email it to me, although, considering all the traffic I've seen on the BBS over the years, I don't think you should worry about anything you post publicly. . I have been hoping to put together a few "skeleton" applications, such that a beginner could get started right away just by fleshing them out or customizing them. I haven't done it yet, but still have hopes. . It might be harder to learn Forth in the abstract than to learn it by picking a specific project and doing it in Forth. So, figure out what you need the computer to do for you and then use Forth to make the computer do it. (Start small.) . I am interested in how a newcomer to Pygmy reacts. I've felt that a software package needs to let the user feel oriented and in-charge as quickly as possible. He can feel oriented and confident in proceeding long before all details are memorized or mastered. At some point, things click (hopefully). Then he knows how to find out any of the details he needs to know. He is no longer "completely lost." I think (1) feedback and (2) a proper "mental model" are important to this feeling of orientation. If you were driving a car and couldn't find out whether you'd steered, accelerated, and braked correctly until the end of the trip (which could occur when you arrive at your planned destination, or when you are dead or in a ditch) ... well, that's what I mean by feedback! -- it needs to be rapid. . Good luck. . -- Frank ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/31/91)
Category 1, Topic 45
Message 78 Sat Mar 30, 1991
L.LISLE1 [Greg] at 18:04 EST
Frank;
I've just started looking at Pygmy and am quite impressed. Having spent 4+
years with Poly4th, I feel right at home. However, before I start changing
things to suit myself, I have a question. Why did you put the disk buffers
under the parameter stack? This will limit the size of the stack and the
degree of recursion. Is there some reason I'm missing?
- L. Greg Lisle -
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/06/91)
Category 1, Topic 45 Message 79 Thu Apr 04, 1991 F.SERGEANT [Frank] at 01:01 CST LGL> Why did you put the disk buffers under the parameter stack? This LGL> will limit the size of the stack and the degree of recursion. . Greg, you've got a good point. The reason I did it that way is I more often change the number of disk buffers than the size of the stacks. However, there is no reason for you not to put the stacks below the disk buffers and TIB. . -- Frank ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/12/91)
Category 1, Topic 45
Message 80 Thu Apr 11, 1991
L.LISLE1 [Greg] at 08:00 EDT
Frank;
In my continued digging, I think I found a transgression against what
_should_ be a cardinal rule, Never change the stack behavior of a
defered word. I kept getting file errors when trying to use SHOW.
I discovered that .HD had been reloaded with a word for use with
SHADOW, but it used the _second_ entry on the stack. Shame on you!
It would also be helpful to note that use of MAKE should be followed with
MORE. MAKE leaves an empty file (obviously) and the EDITOR doesn't like that.
Another suggestion would be the use of a word from the POLY4TH world,
: +LOAD ( n-) BLK @ + LOAD ;
This would allow source load screens to be location independent.
Again, thanks for a slick implimentation.
- L. Greg Lisle -
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/16/91)
Category 1, Topic 45
Message 81 Sun Apr 14, 1991
F.SERGEANT [Frank] at 13:50 CDT
Greg,
You are correct. I should not have used the DEFER'd word .HD in both SHOW
and SHADOW, as once the code for SHADOW has been loaded it screws up SHOW.
The quick solution is to reload just the code for SHOW prior to using SHOW.
Better would be to DEFER a new word .SHD (shadow heading) for use with SHADOW
so it would not disturb .HD used by SHOW.
.
Yes, when you MAKE a file it has a length of zero, and so needs to have MORE
added to it before the editor can access it. An alternative I sometimes use
is DOS's COPY command. For example, if I want to create a new block file
named TEST.SCR I might do
C:\PYG\>COPY YOURFILE.SCR TEST.SCR
from DOS. If the YOURFILE.SCR that comes with Pygmy hasn't been changed,
this will create a TEST.SCR file with 8 empty blocks.
.
I haven't particulary needed +LOAD and +THRU yet for what I do, as my source
code tends to sit at fixed block locations and I'd rather think in fixed
rather than relative block numbers. But, I don't object to them.
.
-- Frank
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/18/91)
Date: 04-13-91 (16:37) Number: 1888 of 1896
To: FRANK SERGEANT Refer#: NONE
From: JAMES MEYER Read: NO
Subj: PYGMY FORTH Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
Frank,
I have recently downloaded Pygmy and am exploring it on my XT
at home. I tried to use it on an AT with EGA at work and had
problems. Using PYGMYC.COM and making the patch for the color
board (CGA?) resulted in a cursor that works fine while compiling,
but not in the screen editor. Has anyone else reported and/or
solved a problem like this?
Jim
---
~ EZ 1.33 ~ YATL...Yet Another Tag Line
~ RNet 1.08D:MetroLink: Data Bit NETWork * Alexandria, VA * (703) 719-9648
PCRelay:DCINFO -> #16 MetroLink (tm) International Network
4.10 DC Info Exchange MetroLink International Hub
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/20/91)
Category 1, Topic 45 Message 83 Fri Apr 19, 1991 F.SERGEANT [Frank] at 00:26 CDT <James Meyer asks about running Pygmy on at AT with EGA> . Jim, first, are you sure you are using version 1.3? The PYGMYC.COM was only used several versions earlier (where PYGMYC.COM was supposed to work on color systems and PYGMY.COM worked on monochrome systems). I thought all the kinks had been worked out by version 1.2 for automatically determining whether the system was color or monochrome. Please let me know which version you are using. . If it is 1.3 then the 1st idea that comes to mind is perhaps some other software has set the EGA into some strange mode (not 80x25 with video buffer starting at $B8000). If so, perhaps you can reset the mode to a plain 'ol CGA compatible mode and see what happens. Let me know all the details you can and I hope we can get it working. . -- Frank ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp