Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Rod Pemberton Newsgroups: comp.lang.forth Subject: Re: Forth Implementations advantages and disadvantages. Date: Sat, 27 May 2017 21:58:26 -0400 Organization: Aioe.org NNTP Server Lines: 54 Message-ID: <20170527215826.4448fc1e@_> References: NNTP-Posting-Host: ZTD62cW/Uw8bymX5ok+0NA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:59954 On Sat, 27 May 2017 09:29:34 -0500 Cecil Bayona wrote: > If the primitives are written in C then it's easy to port it to > another CPU that has a C compiler, just re-compile. For the most part, I think that's true, as my ITC Forth interpreter has it's primitives in C and the rest in Forth. However, IIRC, the loop constructs in Forth use the processor overflow flag. This is not available in C. You'll have to work around this. Another issue I had was with the line buffering that's used by default with C. Each compiler has different implementations of non-buffered input, and sometimes different functions to change the settings. > >> 2. Good and simple to understand. > > That depends on the Forth implemented, since this is for embedded > CPUs, keeping the Forth simple entails being selective about what is > in it, no 2400 word Forth but keeping it under 300 words. Are you wanting the Forth code or C code to be "good and simple to understand"? If most of the code is in Forth and only the primitives are in C, then it'll be understandable to a Forth programmer, for the most part. > >> 3. Small > > A token Forth would be very small since most Forth words would take > one byte. Keep the number of words down to the necessities will help > keep it small. If your Forth is based on primitives, like eForth, then the size is primarily dependent on how many high-level Forth words you create. > >> 4. Fast > > Here is the big issue, items 1-3 make it hard for it to be fast > except in the case of a FPGA CPU, if the CPU will be used a lot and > it needs to be faster, then a re-write of the primitives to use > assembler will speed it up, this is to be done only when the speed is > vital. You'll need 30 to 60 or so primitives to prevent it from being exceptionally slow. These should mostly fit cleanly onto the instruction set of the processor you use. You can speed it up somewhat by using efficient definitions for stack operations and Forth words that execute frequently. Rod Pemberton --