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: How to get Ada to ?cross the chasm?? Date: Fri, 11 May 2018 15:39:24 -0700 Organization: A noiseless patient Spider Message-ID: <87tvrdhl5v.fsf@nightsong.com> References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="4776ca6b408eab45c2cc0c9a5f8c8c74"; logging-data="30044"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/HRC2ES49jWnZWA8kfFp/N" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:Tw+G/vZ1SuidvIArgg1gfkAV6oI= sha1:bE9LlRRxhTb+Fuz09oBdErlYUzI= Xref: reader02.eternal-september.org comp.lang.ada:52304 Date: 2018-05-11T15:39:24-07:00 List-Id: Niklas Holsti writes: > (Your mention of Forth I don't understand. I see Forth as one large > step below C in language level -- cripes, one even has to manage the > stack manually! -- and requiring extremely careful coding to avoid the > program going off the rails. Moreover, I don't see any particular > support in Forth for real-time aspects or control-flow restrictions > such as loops with static iteration bounds.) Forth is interesting and while I'd consider it lower level than C, the Forth newsgroup participants would disagree vociferously. It focuses the mind to the point that someone wrote a book comparing it to Zen meditation. Its implementation techniques are startlingly clever and I'd consider studying and using it to be a worthwhile exercise for any serious programmer. I use it in some personal projects because I like the mental exercise and because of how it forces me to simplify problems to their bare essentials. That said, its heyday was the 1970s-80s minicomputer era and (contra what the Forthers say) doing anything serious with it today seems to me like an exercise in masochism. I'm far faster at C than I am at Forth, the opposite of what Forth programmers claim. Forth is usually implemented as a very simple threaded-code interpreter (the "inner" or "address" interpreter) written in assembly language, plus a source-language interpreter (the "outer" or "text" interpreter) written in Forth itself. The inner interpreter is maybe a few dozen asm instructions and implements a 2-stack VM. The outer interpreter is basically an assembler for the VM, plus it often lets you write definitions directly in assembly language with the assembler itself written in Forth, using Forth syntax. There is sometimes a cooperative multitasker that itself is just a handful of instructions that basically swaps stack pointers around between tasks. The whole implementation is simple enough that the programmer can and does understand and maintain the whole thing, all the way down to the hardware (OS? We don't need no stinking OS). You can have a respectable interactive interpreter in a few KB of program space using maybe 100 bytes of ram. Or you could have a complete IDE-like environment on a minicomputer with 8k of ram and a floppy drive. It's conducive to realtime control applications because there is such a direct mapping between Forth code and machine code, even closer than C in my opinion. When a Forther types "2 2 + ." to the text interpreter they can predict exactly what instructions the machine will run. There's not dozens of layers of libraries between the user program and the machine. There's usually no heap allocation, GC, background tasks, or anything else happening while the program runs. Its main touted feature is its interactivity: in some ways it's more like using a debugger than a compiler. You get some weird piece of poorly documented hardware and you can put Forth on it, and start poking at the control registers (defining functions to bang them in sequence etc.) and figuring out what stuff does. I got a couple of small STM8 8-bit MCU boards from Aliexpress for about 0.5 euro each. They have 8K of program flash and 1k of ram, and they can run a reasonable interactive Forth. Forth must have had the same attraction on 1970s minicomputers that an interactive Python prompt does on PC's today. This book about Forth development methods predated the whole Agile movement by decades(?): http://thinking-forth.sourceforge.net/ Maybe mentioning Agile is poor recommendation here since I guess Ada users have a dim view of Agile. I can sympathize with that, at least as far as production code is concerned. But even when one has to ship reliable production code at the end of the day, it's useful to be able to first slap out a crappy prototype that lets you explore the possible feature space and implementation strategies. Tools like Python and (at the lower level) Forth are great for that. I liked this article although Forthers complain about it and some of their disagreements with it are valid: http://yosefk.com/blog/my-history-with-forth-stack-machines.html > The concept of "dynamic allocation" is interestingly vague. All > real-time applications I've seen have dynamic allocation in various > data buffers and queues, even if they never use the system heap. Yeah I'm used to a much more limited style of realtime system, that uses a few fixed memory locations or maybe fixed sized arrays, plus some simple functions and loops, with no heap allocation after the initialization phase. But of course things can be much more complicated. >> https://github.com/tomahawkins/atom > "Compile-time task scheduling" probably means fixed task frequencies, > rather than event-driven, preemptive tasks, am I right? Pretty much. It's been a while since I tried it, but it is made for HRT and its intended application was motor controllers, so not much complex communication. IIRC the user program is compiled to a single event loop where the different "tasks" each get to look at each event and possily act on it. It is designed for constant-time execution, so instead of if (condition) then f(); else g(); its conditional execution construct (called "mux" instead of "if") compiles into r1 = f() r2 = g() result = condition ? r1 : r2 ; That is, both branches are executed and then the condition selects which value to use. The whole program is constructed that way, so the main loop is supposed to use the exact same number of machine cycles on every pass, no matter what the individual tasks decide to do. > New ideas as hard to get past product assurance people, who tend to > be quite conservative (with good reason). Yep, I'd be conservative about something like that too. In a weird way, even though Forth has no safety checks, its simplicity reflects a form of extreme conservativism.