Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: esp8266 eForth and it's development software Date: Sun, 05 Mar 2017 01:36:47 -0800 Organization: A noiseless patient Spider Lines: 17 Message-ID: <87zih0cbf4.fsf@nightsong.com> References: <878toke53e.fsf@nightsong.com> <874lz8e1ls.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="bfe79aad8260a200788ae8f872ad9256"; logging-data="31399"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HLxwU1VXxxmbl3eEd6EJw" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:s2qtA4V4y/LQNuE9Mbyjo4A5lWs= sha1:vrU84PkBonBye2vE6sun+Y4VjRk= Xref: csiph.com comp.lang.forth:55424 Cecil Bayona writes: > Nothing specific at the moment but efficient doesn't hurt Fair enough, but it would be interesting to compare against micropython or Duktape (micro javascript) or Lua (NodeMCU) or other HLL's that have gotten popular on the 8266. Forth was traditionally implemented as ITC with some code words at the bottom, so it took maybe a 10x speed hit compared to assembler, making it far superior to alternatives like BASIC. Do you think what you're using now is worse than a traditional ITC? In short I wouldn't worry about the interpreter speed until you hit a problem where it's a practical obstacle. Also aren't there lots of small portable Forth-in-C implementations like pForth? Or the 8266 might even be able to run Gforth-embedded. The ESP32 is even more likely to be able to.