milan@MJM.XYPLEX.COM (Milan Merhar) (04/17/91)
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 <offset>" rather than for a "JSR <absolute address>". 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.
S47852EF@ETSUACAD.BITNET ("Frank C. Earl") (04/18/91)
On Wed, 17 Apr 91 09:30:32 EDT Milan Merhar said: >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. Would you mind providing the net with a copy of this program? We have ECBs here at ETSU and I'd bet that there's others out there- Forth could be a good monitor/development environment for the ECB in lieu of the junk monitor program they already have on it... :) Thanks Frank
Mitch.Bradley@ENG.SUN.COM (04/20/91)
> 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. > ... > 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. > ... > 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. > ... > 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. In my opinion, the best fix is to throw out eForth and start with a mature system (F83 comes to mind) that actually addresses at least a few of the many real problems that have to be addressed in order to make a portable system. Problems like byte ordering, alignment, possibly-variable widths of various kernel data items (branch offsets, code fields, does fields, user area offsets, threads, etc), code generation, I/O interface vectors, relocation, and loader formats. To my knowledge, the only portability issue that eForth has addressed is the issue of how many code words you have to write. In my experience, this issue is not a big deal. When I ported my system from 680x0 to SPARC, it only took me a couple of evenings to rewrite all the code words, and my system has relatively many code words (over 100). A few of the code words require some thought and care (FIND , UM/MOD , DODOES), and the rest are total no-brainers (e.g. +, AND , R> , 0< , SWAP). Mitch Bradley, wmb@Eng.Sun.COM