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!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sat, 12 May 2018 12:29:05 +0300 Organization: Tidorum Ltd Message-ID: 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> <87tvrdhl5v.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net AzXTpfxtr+1dUV69CGgT5gxa7p4BzqDaMS+UYDIq+cBT4YeINx Cancel-Lock: sha1:uh01Phlg+mDMF38rx2N6rq2Vxe8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87tvrdhl5v.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52311 Date: 2018-05-12T12:29:05+03:00 List-Id: On 18-05-12 01:39 , Paul Rubin wrote: > 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. Yes. It's weird how some people fall in love with strange things -- like Forth, or Ada... > Its implementation techniques are startlingly clever There have been compilers of higher-level languages that generate threaded code that looks like the code one expects from Forth; on the other hand, I believe there are now Forth compilers that can emit a more conventional kind of code. I'm not sure if threaded code was invented in connection with Forth, or was adopted in Forth because it suited the interactive environment. If you want a thrill (hair-raising kind), have a look at how Gforth implements threaded Forth code by cutting and splicing machine code generated by gcc from C source for the interpreter. > That said, its heyday was the 1970s-80s minicomputer era Around that time, I was using an HP2100 16-bit mini (64 KiB of magnetic core memory) for controlling an astronomical radio telescope and its instruments. To replace the very limited HP-Basic which had been used before, we considered implementing a Forth system -- the commercial Forth costing more than the university was eager to pay. In the end we used HP-Algol instead. The programming process was "interesting". To edit a source code file: load the interactive editor from paper tape, load the source code from paper tape, edit (as in Basic) the lines that need changes, save the edited source on paper tape. To build the program: load the compiler from paper or magnetic tape (fortunately a single-pass compiler), load a source file from paper tape and compile it, get the object on paper tape, repeat for all changed source files. Then splice the new and old object-code tapes together with Scotch tape, load the linker from paper or magnetic tape, feed in the spliced object tapes, get the executable on paper tape, load that tape, press Run. Ah, nostalgia... The interactive Forth had a certain attraction, in comparison. > and (contra what the Forthers say) doing anything > serious with it today seems to me like an exercise in masochism. I agree. There are very few situations were I would consider using Forth; possibly for some very small embedded device that must be reprogrammable on itself, without cross-programming from a PC. > Forth is usually implemented... There is sometimes a cooperative > multitasker that itself is just a handful of instructions that basically > swaps stack pointers around between tasks. I cannot resist to note that I implemented a cooperative multi-tasker for the HP2100 Algol system eulogized above. It was dirt simple: the machine had two working registers and no stack. Some of the users of the earlier Basic-based SW were amazed to see the typewriter terminal printing at the same time as the ADC was reading data at the same time as the magnetic tape was spinning. Not having a stack meant that subprograms were not reentrant, so one had use a certain amount of care in choosing when to switch tasks. > 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. For the "2 2 +" part, yes. For the "." part, not so much. And once the program gets larger, knowing exactly which instructions the compiler will emit for each statement helps little to understand the whole, I think. > Maybe mentioning Agile is poor recommendation here since I guess Ada > users have a dim view of Agile. Agile versus waterfall depends on the project's goals rather than the language, I feel. In some projects -- space on-board SW is typical -- the customer knows what is wanted, based on intense earlier analysis of the mission, its scientific or technical aims, SW/HW trade-offs etc. In agile projects there is flexibility in the scope, the HW, the functionality, everything. IMO Ada is well suited for agile development, because you can refactor things wildly and the compiler will help you put it into shape again. In a less strict language, conflicts or incompatibilities caused by refactoring can stay hidden until the program fails with a run-time error -- much harder to correct. (That said, the support that the GPS IDE currently offers for refactoring is very rudimentary, being limited to renaming things systematically -- usually one identifier at a time :-( ) >> 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. I seem to have difficulty communicating my point here. Do you equate "dynamic" with "heap"? In my view, if your system has a UART and accumulates incoming characters into a line buffer until in comes a CR to end the line, you are allocating space dynamically in the buffer for each incoming character. Now that is an extreme example, but I hope it shows what I am driving at: in principle, if the program uses up space, when needed, in any "memory" that can fill up, it is allocating that space dynamically, even if this "memory" is not the system heap. >>> https://github.com/tomahawkins/atom > ... 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 ; In the WCET analysis community, this coding style is called "single-path programming". There are some advocates, and even some HW development for it. One has to rethink one's algorithms, but it is claimed that the worst case is usually no worse than for a conventional algorithm. > That is, both branches are executed and then the condition selects > which value to use. Another approach is to execute only the selected branch, but to ensure that both branches use the same amount of time, inserting dummy instructions in the shorter branch if needed. There have been posts on comp.arch.embedded form people who are doing that. Of course this approach does not work as well on machines that have variable instruction timing from caches etc. > 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. The problem in a main-loop system is combining high-frequency tasks with low-frequency tasks that do complex computations. The main loop has to suspend and resume the complex computation frequently, which is not so easy unless one does a full task-context switch. >> 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. I am reminded of the Mythbusters TV shows where the goal is to construct just about anything with duct tape :-) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .