Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uakari.primate.wisc.edu!sdd.hp.com!mips!pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: eForth Message-ID: <2746.UUL1.3#5129@willett.pgh.pa.us> Date: 13 May 91 11:56:36 GMT Organization: (n.) to be organized. But that's not important right now. Lines: 38 Category 1, Topic 36 Message 16 Thu May 09, 1991 R.CAVANAUGH [BobC] at 20:25 MDT Thanks for the encouragement, Dennis I would like to bring up some other issues about eForth which I think should be addressed. I am looking at this as if I was going to use this approach for all my embedded processing applications. 1) In debugging embedded processors now, my group uses some sort of ICE in every application. This gives access to registers, memory locations, and conditional breakpoints. How are these types of tools to be provided by eForth? Or is a different type of debugging environment envisioned? How do you typically do it now ? 2) I understand the concept of using MASM (with hand assembly) to generate target images of various processors. I think a much better approach would be to select a table-driven cross assembler such as TASM (not Borland TASM, but the shareware of the same name). What are the reasons for selecting MASM? 3) How is ROMmable code produced and in what format? We use Motorola S- record format for burning our proms, or Intel Hex. Is there a mechanism for this envisioned for eForth? BTW, out of all this I am attempting to port eForth to the Z-8 as my project for this summer in my spare (ha) time, will let you know how it turns out Thanks, --Bobc ----- 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