Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Which scripting for embedded automation? Date: Wed, 29 Jul 2015 18:53:11 -0400 Organization: Aioe.org NNTP Server Lines: 69 Message-ID: References: <0e930740-22d8-4e2b-833f-bb5843437d0d@googlegroups.com> <40eef114-1b88-4c29-8937-f0a708a8e805@googlegroups.com> <2015Jul29.092237@mips.complang.tuwien.ac.at> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:40923 On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl wrote: > "Rod Pemberton" writes: >> Yes. Everything an 8-bit microprocessor can do, and the general >> purpose instructions of 16-bit processors, can be done directly in >> C without needing to use assembly. The only thing missing is a >> carry flag and an overflow flag. > > Yes, these are two things that you cannot express directly in C. > > Another big restriction of C is that you are limited in the kind > of control-flow you can do. This statement was in regards to threaded code, yes? Or, was that meant as a general comment on C's control-flow? > Threaded code? Not in standard C. That's not true. I implemented my ITC Forth interpreter in pure ANSI C, i.e., no special features. It works the exact same way as a Forth interpreter in assembly, i.e.., it implements a virtual machine with W, IP, SP, RP, etc, inner and outer interpreters, dictionary with NFA, CFA, LFA, PFA, etc. The dictionary layout is also identical, except for one additional pointer, to what would've been needed if I had coded it in x86 assembly. The extra pointer was because you don't have control of placement of stored data with C. Of course, it requires a cast here and there, but not much overriding of C's type system. I was working on a different layout that wouldn't require some of the casts and the extra pointer, but it would then require an additional pointer to the name field. Lose one. Gain one. Although, I might be able to reduce the few remaining casts down to one or a few. Most other implementations in C use a switch() statement to effect threaded style code. They don't use actual threaded code. > Tail-call optimization? Neither guaranteed nor commonplace > (in general, not possible). That's up to the compiler ... > Coroutining? Nope. That's not true either. Again, it's just more difficult. C was designed for a single entry to a procedure, i.e., structured code. Simon Tathem's coroutines in C: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html Those are based off of Duff's device which he discusses. Duff's device is an unstructured switch() statement, i.e., no body. It acts slightly differently from a normal C switch() with body {} section. > Prolog-like backtracking? > Nope. I'm not familiar with Prolog, so I have no idea what that is. Clearly, it, like closures, aren't needed within C. Maybe, they're needed within Forth ... ? Is that why you brought them up? Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...