ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/17/90)
Date: 01-15-90 (18:58) Number: 277 To: ALL Refer#: NONE From: STEVEN GAARDER Read: HAS REPLIES Subj: WHAT HAPPENED TO NAUTILUS Status: PUBLIC MESSAGE I have just been handed an old piece of code designed for the Nautilus Systems Cross Compiler, running under cpm and producing z80 code. I need to bring this stuff up to date and would like to find a development environment that can handle it with minimal changes. Any suggestions on what I could use, or where I could at least find a Nautilus systems compiler running on MSDOS? Thanks. 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) (01/17/90)
Date: 01-16-90 (21:03) Number: 286 To: STEVEN GAARDER Refer#: NONE From: RAY DUNCAN Read: NO Subj: WHAT HAPPENED TO NAUTILUS Status: PUBLIC MESSAGE Nautilus Cross Compilers have been extinct for about 4 years. We now sell our own Forth-83 LMI Metacompiler which is a multipass compiler with sophisticated error handling, automatic handling of defining and IMMEDIATE words, and many other features that leave the Nautilus Compiler in the dust. We suggest you purchase the LMI Forth Metacompiler and move forward with that product. We support a variety of 8-bit, 16-bit, and 32-bit targets using the PC and MSDOS as the host development system. 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'
dwp@willett.UUCP (Doug Philips) (01/23/90)
Date: 01-21-90 (23:02) Number: 321
To: DON MADSON Refer#: NONE
From: RAY DUNCAN Read: NO
Subj: WHAT HAPPENED TO NAUTILUS Status: PUBLIC MESSAGE
Z80MU is here for downloading on the LMI Forth Board as the file
Z80MU310.ARC. This is a nice program, I use it myself to test the Z-80
and 8080 targets on my PC.
NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
---
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) (02/02/90)
Date: 02-01-90 (03:07) Number: 368 (Echo) To: GARY SMITH Refer#: 367 From: RAY DUNCAN Read: NO Subj: LMI FORTH(S) Status: PUBLIC MESSAGE The Metacompiler is a compiler-compiler and as such is not completely analogous to a normal Forth programming environment. Some directives or Forth "words" are hardwired and their action can't be changed at compile time. Most of the Metacompiler's special directives (such as HEADERS and -HEADERS) are in this category; they affect the action of the compiler-compiler rather than having any emulated action on the target's compiler (which is being built but is not running). ----- 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/07/90)
Date: 02-02-90 (14:10) Number: 375
To: RAY DUNCAN Refer#: NONE
From: SHANNON VANCE Read: 02-02-90 (17:09)
Subj: MC 3.0 Status: PUBLIC MESSAGE
Oh yeah, I forgot. One more thing..
If the compiler could accept file lists in include statements
we could use our automatic file scanning software to help
build our include (.inc) files.
The preferred syntax would be:
INCLUDE @filename
a .fl extension is assumed, but any extension will work if
specified. The @ symbol seems to be fairly universal in
denoting a filelist.
Shannon Vance
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/28/90)
Date: 02-26-90 (13:23) Number: 467 To: RAY DUNCAN Refer#: NONE From: CHUCK WHITE Read: 02-26-90 (14:08) Subj: 8096 METACOMPILER Status: PUBLIC MESSAGE I'm interested in the Metacompiler for the 8096. I'm currently running a cross-compiled Forth for the 8051 which uses the serial port for as the terminal for interactive debugging. Virtual disks are supported on the PC but I don't use the feature. I cross-compile then load a ROM emulator or burn an EPROM for the target. This would be a minimum requirement for the 8096 system. Does your kernel support a PC host for debugging? Is there a compiler (interpreter) in the target kernel? Would it be best to buy manual? Thanks for your help. Chuck White Reichert Ophthalmic Instruments Buffalo NY 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/28/90)
Date: 02-26-90 (14:08) Number: 471 To: CHUCK WHITE Refer#: 872 From: RAY DUNCAN Read: NO Subj: 8096 METACOMPILER Status: PUBLIC MESSAGE Yes, we do support a PC host for debugging with the 8096 kernel. There is a compiler/interpreter in the target kernel. You can buy the metacompiler manual separately for $35. 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) (07/14/90)
Date: 07-12-90 (20:14) Number: 656 To: ALL Refer#: NONE From: LANCE COLLINS Read: (N/A) Subj: DS5000 Status: PUBLIC MESSAGE I am thinking about embedded systems based on around Dallas products, initially the the DS5000 (an 8051 variant). I would like to have a tiny kernel in the 5000 linked back to a host PC which would have the main development software. Code would be compiled in the PC and downloaded to the 5000. One of the application programs downloadable would be a stand-alone development system. I could do all this from scratch based on previous experience with cross-compiling from 8080 to 8086 and then back to 8080. But why re-invent the wheel? What can I beg, borrow or even buy to get this project started? --- * Via ProDoor 3.0 NET/Mail : Australian Connection Forth Board (Melbourne) 61 3 8091787 ----- 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.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/23/90)
Date: 08-19-90 (21:10) Number: 753 (Echo)
To: ALL Refer#: NONE
From: JOHN SOMERVILLE Read: (N/A)
Subj: PORTING UR/FORTH Status: PUBLIC MESSAGE
What are the steps to porting UR to another chip, say the 68HC11? At
this point all I know is that I would like to create the following
classes of output: Boolean & Ramping functions.
In general could I proceed to develop a simulation on my PC and if
successful then look for a chip with the appropriate charactersitics.
eg.
VARIABLE DUMMY.OUT.1
VARIABLE DUMMY.OUT.2
.
.
.
VARIABLE DUMMY.OUT.n
: STUFF.TO.DUMMY.x ( CHANNEL--) marvelous.happenings ;
Once I am content with the simulation, I could then assign DUMMY.OUT.x
as addresses.
Or is this a poor plan? (Bearing in mind I know little about hardware.)
regards j
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.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/23/90)
Date: 08-20-90 (19:02) Number: 754 (Echo)
To: RAY DUNCAN Refer#: NONE
From: LARRY GABRIEL Read: 08-20-90 (23:35)
Subj: COMMENT Status: PUBLIC MESSAGE
[Sorry about the corruption in this. It seems to have occurred before
I got to it. -dwp]
We are interested in your RTX2000 metacompiler. Do you support or plan
to support the RTX2001? In some of our proposed applications, math
speed is not important, low cost is. ( We are just doing some very
simple logic functions, IF THEN, etc. )
According to your manual on the Metacompiler which we bought from
you a while back, the RTX version of the metacompiler differs in
that the PC is used as a disk server and terminal. Is this function
similar to the Indelko or Innob!m%Y%yqJ5RR&=s{#V7F7wSAa* D-12016e to write
code on an active RTX on one of our
own boards, and I understand that the Harris Blue Box is not capable
of such a function.
I also have heard that you folks wrote some of the code which Harris
offers with or for the Blue Box. How does your metacompiler differ?
Thank you very much for your time. I will look later here, or if
you would like, our # is 818-458-2742. Thanks....Larry Gabriel
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 dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/23/90)
Date: 08-20-90 (23:35) Number: 756 (Echo) To: LARRY GABRIEL Refer#: 1601 From: RAY DUNCAN Read: NO Subj: COMMENT Status: PUBLIC MESSAGE We can supply the code changes that are needed for the RTX2001, if you need them. The RTX version of the metacompiler runs on a PC and generates an executable image in a disk file on the PC, like all the other versions of the Metacompiler. You then ship this image onto the RTX2000 system, by burning it into EPROM, downloading it into RAM, or whatever. Once the image is there, you have an interactive Forth system running on the RTX2000 that can use the PC as a terminal and a disk drive (transferring stuff over the serial link). You can debug words individually and compile new code on the RTX2000, rather than having to recompile the entire RTX2000 system with the metacompiler each time you want to make a little change. We didn't write any of the code Harris supplies. However their target compiler runs *on top of* our PC/FORTH product. They bought PC/FORTH and used it for their development environment, and they bundle a copy of PC/FORTH with all their Blue Boxes (or they used to, anyway, I don't know what they are doing these days). That is the only connection between Harris and us... we don't really have a close relationship with them, unfortunately -- we hardly ever hear from them! 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 dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
To: RAY DUNCAN Refer#: NONE
From: SHANNON VANCE Read: 10-18-90 (23:50)
Subj: METACOMPILER Status: PUBLIC MESSAGE
Ray;
I have been working on a generalized software development system
for the programmers here at SAGE. We have adopted the Pansophic line
of version control and make utilities. In trying to integrate the LMI
metacompiler into this system I have run across many problems. There are
often workarounds for these problems, but often these are so odious
that even considering them gives me a stomach ache. What it comes down
to
is: I need some help from LMI. I consider the things that I wish for to
be features that would naturally be included in any serious compiler.
How soon can we expect a new release of the meta-compiler? Will the
things
I have asked for be included? Here is the list of things that
I sent before, with some new items added.
1) The bug - In ROMZ80 land.
FORGET doesn't work with vocabularies.
If a vocabulary is declared at compile time,
FORGET will crash the system.
If a vocabulary is declared at run time,
FORGET will forget all words in the vocabulary,
and the vocabulary itself.
2) I would like to see a command that does
whatever is done when the metacompiler
finishes a compile. That way I can do a CHECKSUM
at the end of a compile and it would accurately
reflect the compiled image. Without this feature the
CHECKSUM command is fairly useless. (unless another compile
is done based on the image that was just written)
3) I would like a MACRO-VARIABLE that would essentially
act like an EQU that can be re-valued during a compile.
In other words a variable that doesn't appear in the
target image.
4) I would like a STRING-MACRO-VARIABLE. This would be handy
for vectoring pathnames in an include file. (among other things)
example:
MACRO-$VAR $COMPILE_PATH
" C:\SOURCE" $COMPILE_PATH $!
.
.
.
INCLUDE $COMPILE_PATH\APPLIC.TXT
5) I would like to be able to set the return code for
testing in batch files and the like.
6) I need to be able to set the path for where the compiler
will put it's output files. This will make it possible to compile
different "flavors" of a product without copying files to and
from a "save" directory.
7) I need to be able to use environment variables in compiles. This is
somewhat like item #4. Instead of a literal string, $COMPILE_PATH
would be an environment variable.
eg. "INCLUDE %COMPILE_PATH%\APPLIC.TXT"
8) Being able to spawn a DOS command would be extremely helpful. It
would also be necessary to test the return code from the DOS command.
9) I would like to be able to test the values of environment variables
and STRING-MACRO-VARIABLES for .IF .THEN statements.
10) I need to be able to break out of a compile without crashing my
workstation.
Thanks for an exellent product....Shannon Vance
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: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
To: SHANNON VANCE Refer#: 1776 From: RAY DUNCAN Read: NO Subj: METACOMPILER Status: PUBLIC MESSAGE 1. Have you tried the file ROMFORGE.ZIP in conference 5? As far as I know this version of Forget is "good." 2. The metacompiler doesn't do any magic hidden things at the end of the compile. All changes to the image are explicit and are in the target's source file (e.g. HERE INIT-DP ! and so on). You just need to calculate the checksum AFTER these interpreted actions at the end of the compilation. Or am I missing something here? 3. This is reasonable and we plan to do it. However there are some funny implications by the fact that the Metacompiler makes 2 passes and forward references are allowed. You might not get exactly what you expect if you aren't careful to avoid forward references. 4. A nonzero return code, by convention, means an error has occurred. This is pretty standard behavior for compilers and other utilities. How could we preserve this (thereby allowing people (including ourselves) to use the Metacompiler with a MAKE utility) and still give you the ability to set ANY return code you want at the end of compilation? 5. The metacompiler currently puts the output files wherever it found the input files. It seems reasonable to me to specify a different path for the output; I'll look at this. 6. Using an environment variable as part of a path sounds reasonable to me, and shouldn't be too hard to add. 7. I'm curious about what sort of DOS command you would want to spawn during a metacompile (which is not an interactive process). There is very little memory around when the metacompiler is running; I doubt if there is enough to run any problem of reasonable size. We use just about all of it for symbol tables & stuff that we don't want to page in and out from disk (the only thing that we page is the image file). 8. Testing environment variables for .IF statements should be possible. But I'm not sure I'm ready to commit to this sort of thing. This would lead us into trying to make all the string operators "interpretable" at metacompile time and has other hidden ramifications. 32. If you are using control-Break to terminate a metacompile run, I can't tell you anything except the behavior of Control-Break varies from one ROM BIOS to another. It works ok on my machines, and we have special code in there to handle various ROM BIOS peculiarities, but we can't check all possible machines. Perhaps we'll just have to disable the control-break capability altogether during metacompilation and monitor the keyboard for entry of some other character (e.g. Control-C). 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: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/22/90)
To: RAY DUNCAN Refer#: NONE From: SHANNON VANCE Read: 10-19-90 (18:22) Subj: METACOMPILER Status: PUBLIC MESSAGE Thanks for the speedy reply. I don't really have anything specific in mind for the DOS command. It just seems that this capability would be used for special circumstances. I forgot to mention that we need to be able to specify the path for intermediate files (.img and .sym) if they are to be directed to another path by previous compiles. In other words, if a compile puts it's .img and .sym files in a seperate directory from the input file, the subsequent compile needs to know where to find these files. I consider being able to test environment variables to be of secondary importance to using them. As for usage; if they could be freely usable as any group of characters, they could be, in effect, a macro that is defined at the operating system level. As for the ^brk problem. We have clones. Always have. We have many different styles: Everex, Milex, etc. They are connected to a Novell LAN. All of them crash when trying to abort from compiles. By the way, have you seen JForth by Delta Research? It is a remarkable accomplishment. They are in San Rafael, and mainly support the Amiga. Thats about all. Thanks again, Shannon Vance 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: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/22/90)
To: RAY DUNCAN Refer#: NONE
From: JEFF DANFORTH Read: 10-19-90 (18:28)
Subj: SCREEN PROBLEMS W/ MC Status: PUBLIC MESSAGE
HELLP!
I was using both PC-FORTH and MC (v 2.1) without a hitch on a Leading
Edge up to about 2 years ago, then packed it away.
On resurrecting the tool to run on my Compaq LTE/286 yesterday I found
the screens junked up when PC-FORTH is installed for a PC. I simply am
using the UFORTH.COM renamed, without taking on a screen driver, and
this is just fine, it seems.
BUT, the Metacompiler does not seem so handily dealt with. What
happens is this - the program seems to work alright, except the screen
takes on a BOLD sort of underline bar beneath every character on the
screen! This is not only inconvenient to see, but the screen goes off
the screen, if you catch my drigt, as a result of these bar lines.
I need to use this tool! But I am constrained to my LTE machine, also.
So,
Do you have a solution? Another, more generic MC without this funny
quirK w/r my Compaq LTE (which supposedly is CGA compatible)?
And, if can I get it on 3.5" media, which would be ever so much
handier?
HELP!
You can reach me @ Jeff Danforth
(503) 645-3735 (Gratefully yours,
Me )
thanks
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: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/22/90)
To: RAY DUNCAN Refer#: NONE
From: SHANNON VANCE Read: 10-19-90 (18:29)
Subj: META COMPILER Status: PUBLIC MESSAGE
Ray,
I'm pretty sure that you write vocabulary links at the end of a
compile.
I declared several vocabularies in one compile and manually linked them
to code that is compiled in subsequent compiles. I write out the section
of compiled code that contains these links with a BSAVE command. Later I
load this section with a BLOAD command. The links should be there. When
the file is written the links disappear. (are set to zero again). There
must
be something that happens implicitly on exit that I have no control
over.
Shannon Vance
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: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/22/90)
To: JEFF DANFORTH Refer#: 1781 From: RAY DUNCAN Read: NO Subj: SCREEN PROBLEMS W/ MC Status: PUBLIC MESSAGE The version of the metacompiler you are using is a bit out of date. But I don't know why it wouldn't run on a Compaq LTE. You might try downloading the current version from conference 5, and see if that works better. If you don't have the password for the download, let me know. Regarding PC/FORTH, try installing the CLONE driver instead of the PCVIDEO driver. 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: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/22/90)
To: SHANNON VANCE Refer#: 1783 From: RAY DUNCAN Read: NO Subj: META COMPILER Status: PUBLIC MESSAGE You are so right, we go and update the vocabulary link fields at the end of the compile. OK, now I can see what you need. 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: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/10/90)
Category 3, Topic 27 Message 40 Sun Dec 09, 1990 B.RODRIGUEZ2 [Brad] at 09:44 EST > Admittedly, metacompilers are tricky, but I don't think that it is > as bad as all that. [Examples.] Fair enough. I haven't tried any of the ones you mention. I struggled through the early Nautilus compiler, Cassady's MetaForth, a similar compiler by Charles Curley, and the polyForth target compiler. I was able to use the first three of these "cookbook" fashion -- i.e., leave it set up as the author has, and make your source code look like his -- but I wasn't able to make them do what _I_ want. (Except for the polyForth compiler, where I had the benefit of personal instruction by the author(s), i.e., I took the Forth, Inc. class. I like this compiler, but I couldn't afford it.) Perhaps this is less a comment about metacompilers, and more a comment about metacompiler documentation. Now that I've "rolled my own" I find I understand others much better. -Brad ----- 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/28/91)
Date: 01-25-91 (10:10) Number: 975 of 976 (Echo) To: JOSEPH IMMEL Refer#: NONE From: RAY DUNCAN Read: NO Subj: COMMENT Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) The proper serial port initialization for your board will depend on the CPU clock speed and other factors (e.g. the model of 80x96 you are using). We test the code with our board but customization of the startup code for your hardware environment is your responsibility --- this includes serial port initialization, memory map, and so on. The directives ROM and RAM are clearly described in the manual. ROM controls the starting address and length of the ROM memory space. RAM controls the starting address and length of the RAM memory space, which contains the variables, stacks, and any code that is compiled interactively *when the target is running.* For testing purposes we often set ROM and RAM up so that both use memory that actually lies within RAM on the evaluation board. This allows you to use the on-board monitor on the board to download the executable image into RAM and then run it immediately, without the hassle of burning new EPROMs each time. In any event, whatever memory you declare as ROM (even if it is physically, actually, RAM memory) is memory that is viewed as read-only by the metacompiler. The address ranges for ROM and RAM directives should *never* overlap. The compiler sees them as two different address spaces -- the ROM space is writable at metacompilation time and read-only at execution time, and the RAM space is not accessable at metacompilation time (only allocatable) and is read-write at execution time. I have authorized you for conference #5. This is the metacompiler support conference, and you can download free updates to your compiler from that conference as they are released. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- 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 3, Topic 27 Message 57 Sat Feb 23, 1991 F.SERGEANT [Frank] at 15:25 CST >... the advantages of FOR .. NEXT over DO .. LOOP are just not great >enough to justify all the fuss and effort of changing it. . For me, personally, it was well worth my changing to FOR ... NEXT. Whether the ANSI standards committee should recognize it yet as standard Forth is another question. I have previously suggested that FOR ... NEXT may be too new, and therefore not yet part of standard Forth at all. I think it will become standard Forth eventually. . >There is one serious problem with FOR .. NEXT nowadays: I don't know >what it means anymore. It's original meaning is to execute the loop >n+1 times, but now in Rob's and Frank's systems, it executes n times. . Yes, this concerns me as well. This is another reason I might prefer to omit FOR ... NEXT from the ANSI standard until experience throughout the Forth community shakes this out. I am very happy that FOR should execute the loop u times rather than u+1 times. The compromise I've reached with myself over this is that on occasion I may have to explain which FOR is meant. I feel FOR ... NEXT is still too new to say that such a long tradition already exists for u+1 that an inferior name ( such as ?FOR) must be chosen for the preferred action. . >(There is one less-serious problem too: what is the name of the FOR >.. NEXT loop index?). . Yes, I am not completely insensitive to this as a problem for people who use both DO ... LOOP and FOR ... NEXT. I'm only using FOR ... NEXT and so have no problem calling the index I. At the same time, the weight of tradition leads me to accept that I is the standard name for DO ... LOOP's index. Perhaps over the years as and if FOR ... NEXT becomes standard, so will its index's name. I'm starting in that direction by using I for FOR ... NEXT and nothing for DO ... LOOP, and acknowledge that my usage is not yet standard. . -- 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/12/91)
Date: 03-07-91 (17:42) Number: 1455 of 1463 (Echo) To: JOSEPH IMMEL Refer#: 1440 From: RAY DUNCAN Read: NO Subj: COMMENT Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Your message came over the net to us. It appears from your message that you are using the LMI Metacompiler to put a Forth kernel on a Vesta systems board. I am suprised that you didn't get a Forth system *with* the Vesta board, because I know Vesta has one for the 80196. In any event, if you *do* have the LMI metacompiler and you *are* having trouble getting the Forth running, please get in touch with us either via the net or by dialing our BBS directly. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- 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 3, Topic 27
Message 59 Sat Mar 30, 1991
B.SUTTON1 at 17:34 EST
Does anyone know anything about the F83XT that I received on my public domain
f83 system? I've just converted from CP/M to a 386 and am having a heck of a
time metacompiling this stuff.
I was hoping to use the F83xt because of the separated heads, but I seem to be
missing HEADS.BLK that the metacompiler is requesting. Does anyone know
anything about this?
Also, I've tried to simply forget the extraneous definitions (down thru MARK)
and to try to rebuild the system by loading extendxt.blk, but this keeps
crashing. I've tried clearing all the vectored words I can find that might be
causing this, but to no avail.
Finally, I tried metacompiling the vanilla f83, but the f83.com I have doesn't
seem to be compiled from the source code on the disk -- I think it was QUIT
that was different, and caused the metacompilation to abort.
Any help would be appreciated.
-- Brian
-----
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) (06/01/91)
Date: 05-28-91 (18:02) Number: 56 of 61 (Echo) To: SHANNON VANCE Refer#: NONE From: RAY DUNCAN Read: 05-29-91 (11:45) Subj: METACOMPILER Z80 Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) See my message on conference #5. Basically, I can't duplicate your problem. In the memory configuration you described, everything works fine for me (i.e. RAM based at E100H with the standard ROMZ80 kernel and Software Floating Point included). NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- 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