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.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Forth and others (Was Re: How to get Ada to ?cross the chasm??) Date: Sun, 13 May 2018 00:27:52 +0300 Organization: Tidorum Ltd Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.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> <87sh6w7mac.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net o4Os5q+gRsh2h7cGprOUGAf2ml8bvjTfREGBJOp1v1O56qInKQ Cancel-Lock: sha1:nQMrjDCRiAAhY09WfHu7X+v2Zm0= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87sh6w7mac.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52328 Date: 2018-05-13T00:27:52+03:00 List-Id: (I changed the Subject as it was drifting so much off-topic.) This discussion is degenerating into anecdotes about the bad-old-days of computing. But perhaps it is good to be reminded, now and then, how much better things are today :-) On 18-05-12 21:37 , Paul Rubin wrote: > Niklas Holsti writes: >>> 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; > > Sure, threaded code has been around forever, but Forth's cleverness goes > way beyond that: see Yosefk's article that I linked to. Yeah, I know about the syntax extensibility and "immediate" programming. But to me, considering practical programming, it is part of the "frightfulness" of Forth. I believe that Rust has a syntax macro scheme that goes in that direction, but not so far. 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. >> an HP2100 16-bit mini... we considered implementing a Forth system -- >> the commercial Forth costing more than the university was eager to >> pay. ... > I don't have the impression that the commercial Forths of the era > (Polyforth?) were very expensive ... but I don't know your university's > budget or what Forth Inc was actually charging. The university's budgeting principle, at least for astronomy, seemed to be: staff work is free (we have to pay you anyway, we don't much care what you do, and we can't fire you easily) but you have to fight for any cash you might want for buying stuff. I don't remember how much Forth Inc asked, and we probably did not know about any other sources of Forth implementations. >> 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... > > Yikes! Yeah people like Forth because it avoided that type of thing. > BASIC might have been another possibility? As I wrote, BASIC was used previously at this site. However, the applications were exceeding the abilities of BASIC. 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! The HP-BASIC in use allowed variable identifiers of the form: one letter A-Z followed by one optional decimal digit. My boss at the time was the director of the radio telescope site and had written many of the BASIC programs. For each BASIC program he had a paper sheet ruled with eleven columns, for the digits 0-9 and "no digit", and rows A-Z, with ticks in the letter-digit boxes for the variables used in the program. I believe the BASIC system had no "search" function or "list variables" function, so this was the only way he had of keeping track of his variables, short of reading through all of the source code of the program. Naturally, REM comments were used very sparingly, because they consumed memory, and consumed paper tape. And each REM used up a line number, so you could not insert a REM between lines 110 and 111 without renumbering the program, and then you lost your own memory of which line numbers were which subroutine for GOSUB. And now these paper sheets were filling up, with few or no empty boxes left. So the programmer would have had to start reusing variables for different purposes in different parts of the program. Of course this BASIC had no local variables. Forth or Algol would solve this problem, and increase execution speed too. I cannot resist relating that while Algol solved the problem with the identifier space filling up, we ran into another problem involving programs with many variables: As the machine had no stack, all variables, local as well as global, were statically allocated locations in RAM. The HP2100 had instructions which could more easily access the "base page" of RAM, a chunk of RAM (I forget the size) starting from address zero. The Algol compiler allocated many variables (I believe all scalar variables) in the base page. If you had too many such variables -- as we of course had, after a while -- the program failed to link, due to base-page overflow, although there was plenty of RAM left at higher addresses. Being at the time young and full of vim, I made a post-compiler program (in Algol) that read in the relocatable object-code tape produced by the Algol compiler and punched out a relocatable object-code tape that was altered to eliminate or reduce base-page use (I forget the method I used, but it may have been to make all references indirect via the base page, so allocating only one base-page word for each variable). That saved the day, and were were able to write, compile, and link the programs we needed. Later on, the HP2100 system was replaced by a MicroVAX and DEC Ada. So now we are almost back on topic; but I have to report that, even later, when I was no longer working there, Ada was replaced by some curly-bracket languages. >> 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. > > Atom has some stuff to help with that. You might like the CUFP slides, > that are still in wayback: > > https://web.archive.org/web/20131220122421/http://cufp.galois.com/2008/slides/HawkinsTom.pdf 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. Maybe it is easy to do in Haskell (perhaps save a continuation?) but one of the slides suggests that Atom generates C code ("returns single C function to be called at base rate"), and suspend/resume is not easy in C. As an example of this problem, one of my colleagues used a main-loop design for the control SW for the MIXS and SIXS instruments on the ESA Bepi-Colombo Mercury orbiter (to be launched in October, I believe). Each second of real time is divided into 1000 slices of one millisecond each, and various small "tasks", similar to Atom "rules", are executed in these slices, spread across the 1000 slots according to the desired frequency of each "task". However, in several cases the "tasks" want to execute loops that take too long to fit in a slot, so the loop has to be stopped (suspended) and the stop point (loop counter) stored, to be resumed in a later slot. This complicates the program logic considerably for those "tasks", especially for nested loops. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .