Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!swrinde!ucsd!ucbvax!MJM.XYPLEX.COM!milan From: milan@MJM.XYPLEX.COM (Milan Merhar) Newsgroups: comp.lang.forth Subject: eFORTH for 68000 Message-ID: <9104171506.AA27424@ucbvax.Berkeley.EDU> Date: 17 Apr 91 13:30:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Milan Merhar Organization: The Internet Lines: 48 I recently did a port of eFORTH to a generic 68000 platform, starting with Dr. Richard Haskell's 68E4TH for the Motorola Educational Computer Board. I found a bug, plus a couple of things that probably won't affect use in that ECB environment, but were no good when the code was ported to a system with larger address space. ****** On a separate subject, can anyone point me to a public system on the Internet that has Forth-related files? Most things I have come off Genie, but using FTP is so much more convenient than Zmodem at 1200 baud! ***** If anybody's interested, here's what I had to fix in eFORTH: The UM/MOD code routine is incorrect; it exits on the first 0 bit found in the result, rather than iterating thru all bits. (If anybody needs the corrected code, contact me directly.) The constant value CALLL used to represent the "JSR" instruction is the value for a "JSR " rather than for a "JSR ". It won't work as desired for addresses above 0x7FFF. The correct value is decimal 20153. The "CALL," routine attempts to put down a JSR instruction by taking the opcode as a literal and then doing a "comma". Unfortunately, you can only access dictionary space as cells ( 32-bits at a time), while a "JSR" opcode is only 16-bits. As a quick fix, use the literal value for the opcode sequence " NOP JSR" or decimal 1316048569. The use of ALIGNED to find the end of strings may not work for strings built by an arbitrary macroassembler, because it understands word-alignment but not longword-alignment. Either make sure that all string lengths are multiples of 4 bytes, or rewrite everything that uses ALIGNED to "do the right thing" if strings are merely word-aligned. Also note that there is a difference between something being a multiple of 4 bytes in length, and having an ending address that is longword-aligned. This may be important if you are relocating the code or running it thru a linker. In INTERPRET, the "AT" should be "CAT"; you're picking up the string length. The use of the value MASKK as a compile-time mask to pick up the immediate and compile-only bits of a name field is incorrect. It assumes 80X86 byte-order. The best fix is to rewrite FIND.