Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail From: Lars Brinkhoff Newsgroups: comp.lang.forth Subject: Re: Forth in Javascript? Organization: nocrew References: <29323fdc-9fb6-49c6-afd9-47b1865d1d63@googlegroups.com> <20170503035336.0ddeb1c8@_> <86lgqegxlt.fsf@molnjunk.nocrew.org> Date: Wed, 03 May 2017 19:36:20 +0200 Message-ID: <86a86thmgb.fsf@molnjunk.nocrew.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:3T5JOI7xoPZVJ8WdetjW1BMaKnw= MIME-Version: 1.0 Content-Type: text/plain Lines: 12 NNTP-Posting-Host: 178.18.91.250 X-Trace: news.sunsite.dk DXC=BCn>]SYZ9SO[1HBfORCSCcSD5J_h8H;EFSI2Ic:1WDKBS X-Complaints-To: staff@sunsite.dk Xref: csiph.com comp.lang.forth:58602 Brad Eckert writes: > From the repositories I looked at, they are all written in > JavaScript. No surprise, but I'd rather see a JS kernel loading a > bunch of Forth. I think a bytecode interpreter implemented as a giant > switch statement would be pretty fast. The asm.js target in my Forth is like that. One part of the kernel is written in Forth, and the other part consists of primitives written in JavaScript. The kernel loads the rest of the system from Forth source. Every primitive has a unique ID, which is used by a switch statement in the inner interpreter.