From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: Forth and others (Was Re: How to get Ada to ?cross the chasm??) Date: Sat, 12 May 2018 19:21:15 -0700 Organization: A noiseless patient Spider Message-ID: <874ljcthwk.fsf@nightsong.com> References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> <87tvrdhl5v.fsf@nightsong.com> <87sh6w7mac.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="c82ca7f9f25fd066772aef1e7a55ff31"; logging-data="11723"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+CXjXqpXLjVbr34CNWn4vy" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:Rt+F/FBF6mKS/lfy9vo+ZFRjjJY= sha1:gE9pmoHINUAL39pE+XOVW4UCPwc= Xref: reader02.eternal-september.org comp.lang.ada:52329 Date: 2018-05-12T19:21:15-07:00 List-Id: Niklas Holsti writes: > Yeah, I know about the syntax extensibility and "immediate" > programming. But to me, considering practical programming, it is part > of the "frightfulness" of Forth. Of course. Calling something a work of genius is not necessarily nice. It might be a work of evil genius ;-). Anyway though Forth is fiendishly clever beyond the sum of its parts. It's a combination of ideas that are individually no more than cute, but it all fits together in a cohesive and ok frightening way ;). The one-pass assembler/compiler and the (no longer much used) block storage system were other parts. > On the theoretical level, I admit that it is interesting to see how > far the basic Forth machine can be expanded in various directions by > such definitions. Rather like demonstrating the Turing completeness of > some very small set of machine instructions. Meh, if you want a minimal theoretical machine, try SK combinator calculus. Forth was nuts and bolts (im)practical, very much about wringing maximum use from those old small machines. > I don't remember how much Forth Inc asked, and we probably did not > know about any other sources of Forth implementations. I don't know if eForth existed in that era but it's extremely easy to port. It's written in itself so there's a bootstrapping process were you code 20 or so primitives in assembler (a handful of instructions each) and that's enough to make it run. This is what I use on the STM8 and it takes about 4k of program space. > As I wrote, BASIC was used previously at this sit... It was not fast > enough, it did not do multi-tasking, and -- hold on to your hat -- the > programs were running out of variable identifiers! Heh, but BASIC had arrays?!! So A(1), A(2) etc could be used for different purposes ;). It looks like you can still run HP-2100 ALGOL under emulation: http://simh.trailing-edge.com/pdf/hp2100_doc.pdf http://simh.trailing-edge.com/docs/hp2100_algol_howto_doc.txt > The HP2100 had instructions which could more easily access the "base > page" of RAM,... Yeah that's pretty standard in old processors including more recent ones like the 6502 (still used by Forthers with old Commodore 64's). > I made a post-compiler program (in Algol) that ... punched out a > relocatable object-code tape that was altered to eliminate or reduce > base-page use Interesting that the HP compiler didn't deal with this issue itself. Machines like that were mostly before my time so I wonder what the usual strategies were. I think the 8051 MCU (still used in embedded systems today) has the same design and there are lots of C compilers for it so they must handle it somehow. The base page is 128 or 256 bytes iirc. > [Atom] Sorry, I do not see where that presentation addresses this > issue of how to suspend and resume a complex computation which has > lots of state. Well I think the idea is you just have a few variables for the state, and each pass through the main loop does a single iteration of whatever loop your computation was doing, then updates the variables. I don't know if the approach is suitable for anything extremely complicated > one of the slides suggests that Atom generates C code ("returns single > C function to be called at base rate") Yes it just generates a chunk of C code. I remembered it generating a big loop but it's been a while, so yeah, it's probably a single function that you call from a loop that you write yourself. It could be adapted straightforwardly to produce Ada code or whatever instead, if someone wanted that. It's good to be reminded of it since it occurs to me that I have a project it could actually be good for, running one of those multicolored LED strips that you control with precisely timed pulses. I've actually been planning to do that in Forth but Atom is another possibility. > control SW for the MIXS and SIXS instruments on the ESA Bepi-Colombo > Mercury orbiter... Each second of real time is divided into 1000 > slices of one millisecond each, and various small "tasks", similar to > Atom "rules"... I wonder if that is too complicated to really fit Atom's single-path approach. In the example hydraulic app, there weren't many things going on, but they had to happen exactly on schedule.