Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: Forth Implementation Message-ID: <1840.UUL1.3#5129@willett.pgh.pa.us> Date: 10 Oct 90 01:19:13 GMT Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 100 Category 3, Topic 24 Message 86 Mon Oct 08, 1990 F.SERGEANT [Frank] at 22:20 CDT To Vance Heron, regarding cross-(meta)-compilation in Pygmy Forth. VH> Given a Forth system like PYGMY (I really love it - thank you VH> Frank) how could I port it to a 68000 box ??? How did Frank get VH> his 1st interpreter up so he could interpret the rest ?? Believe it or not, I actually plan to answer both of the above questions. My latest answer to "should Forth be written in assembler or in Forth?" is it definitely should be written in Forth, at least most of the time, but there can be cases where it might need to be distributed as an assembly listing. Are we talking about (1) Porting to a different processor or (2) distributing to a new Forther a system that has already been written for his system. There are gray areas, e.g. sending a Forth system for the PC to someone who has a "clone" with video RAM at a "wrong" location. He can't quite run it without making some changes. He should, though, be able to look at the source code (even if it is in blocks. I have several generally available programs that will display blocks, e.g. the HEX mode of XTREE). Then, with DOS's DEBUG program or various other file or memory editing programs he could patch the video RAM address(es) to suit his own system. Not as smooth as sending him a copy that will run without patching, you say? An alternative would be to send him the source code in assembly language and let him use that listing as a guide for his patching, or, IF he had a compatible assembler and knew how to use it, he could edit the assembly source and re- assemble. That also might not be smooth, depending on which tools and what knowledge the recipient had. When I previously expressed my preference for distributing Forth in Forth, I was refering to the #2 case. There I see no point in sending him a paper assembly listing when you can send him a disk that will run. Then, since he can run Forth, I think it is superior for him to have his Forth's source code also written in Forth. If we send him a Forth that must be compiled from that Forth before it will run so that he can use it to compile the Forth that he wants to compile, we get into the bootstrap problem. He's in a similar position if we send him assembly source and he doesn't have an assembler. If we include a paper assembly listing, including the hex object code, he can type in the object directly (and painfully). There again, he might not have DEBUG or an equivalent monitor program to allow him to do that. So we say everyone can be expected to have an assembler, at least an equivalent to DOS's DEBUG, but not be expected to have a Forth. However, the "assembler" listings of Forth that I've looked at, including FIG, were not pure assembler. They typically have the code words written in assembler and various (fairly opague) macro tricks to get the assembler to lay down headers and colon definition lists. That is one reason I recommend Forth in Forth: readability. As proof, I say again, download EFORTH and compare its assembly listing with its Forth listing; see which you think is more readable. And, which, in the case of EFORTH, was it really written in and which was the derivative listing? I had the opportunity to ask Bill Muench that question last week in San Francisco. He tells me he wrote it in Forth and Ting translated it to assembler. So, at best, I feel the assembly listing approach is only to be used if nothing else will work to give you a running Forth system. Thereafter, abandon the assembly listing and work in Forth. ANSWER #2: I started with the FIG listing for the 6809 and entered the (almost unreadable) hex codes into a Radio Shack Color Computer thru a monitor program that I'd written in BASIC, saving intermediate stages to cassette tape. Once that was done, I re-wrote FIG Forth for the 6809, wrote my meta-compiler & 6809 assembler, and re-gen'd my system. Using that system and its meta-compiler, I cross- (meta)-compiled Forths for the 8088 and the 68000. The first step was to write a Forth assembler for the target processor that would run on my Forth on the Color Computer. (Boy was I glad when I moved from cassette tape to a disk drive!) The next step was to re- write the code words in that new assembly language, and adjust for RAM and I/O locations in the target system, and then run that new source code through the meta-compiler. Simple. After I finally got a PC, I primarily used L&P's F83. That was my platform for generating Pygmy Forth for the 1st time. ANSWER #1: If you have access to a PC, so that you can run Pygmy, then just use Pygmy on the PC to generate a version for the 68000. If you don't want to do that, you might send me your 68000 system and I might do it for you, as I want to have Pygmy running on various processors. I already have an earlier version of Pygmy running (from EPROM) on a breadboarded Zilog S8 system. Anyway, here's how you do it: first write a 68000 assembler that runs in Pygmy on the PC but generates 68000 opcodes. Watch, naturally, for byte order and for even addresses. You might shorten this step by starting with one of the 68000 Forth assemblers that have been published. Then, using Pygmy & its editor on the PC, re-write all the code words that are currently in 80x8x assembly language into their equivalents in 68000 assembly language. Look over operating system calls, etc. You could use a central next instead of in-line, at least to start with, and put a trace or single stepping routine in it to display the stacks and IP etc. Load the code, generating an image in the PC's memory of the 68000 version of Pygmy. Save it to disk. Transfer it (via serial ports, I suppose) to your 68000 system and try it out. The 68000's single-stepping, debugging monitor will come in very handy, combined with the Forth level single stepping I mentioned above. -- Frank ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp