Space-Related Applications of Forth (1998) | Hacker News Reader

Space-Related Applications of Forth (1998)

web.archive.org

61 pointssusam10 comments

I worked at the Center for Astrophysics and Space Sciences at UCSD for a time in the early 1990s on the Electron Drift Instrument. I wrote 90% of the code (250KB, or 250 screens, of 32 bit LMI 386 Forth (IIRC), that controlled the entire testing apparatus for the device. This included a stepper motor, channel plate (to detect single electrons; similar tech to night vision devices), and several electron guns. Low level device control. DMA. A rudimentary but usable GUI. Complex floating point math routines. All in Forth. I still have the code.

> I still have the code.

Any chance of the code being released open source? I don't imagine anyone testing a spacecraft in their garage, but at some point, the must arise full-time software historians using automated tools to search through all available history of code. It's very difficult to know what they'll find useful centuries in the future.

Or it coud at least be donated to the Computer History Museum or Archive.org to be preserved. :)

Probably worth noting that many of these applications used the Harris RTX2010 CPU. This was based on Charles Moore's (inventor of Forth language) work on two-stack CPU design ie: CPUs based on the Forth VM architecture. These machines built by Harris were rad-hardened silicon on sapphire and so were deemed good for space applications.

The CPU could run 12 MIPS with a 10 MHZ clock while having no pipeline. Rather instructions were bit encoded in a single memory cell so some could be executed in parallel.

Single cycle sub-routine call with zero overhead for return from sub-routine. Two cycle interrupt. (if memory serves me well) Pretty cool.

This CPU was used for the CDMS in the Rosseta spacecraft.[1][2]

"CDMS is in charge of controlling the whole Lander operation, including preparations for separation from the orbiter, thermal and power management, as well as separation, descent and touch down. In addition to playing an essential role in controlling the whole landing scenario, CDMS has the following tasks to perform on the comet’s surface: to receive and execute telecommands coming from Earth, to collect and send science and housekeeping information of Lander’s subsystems and scientific experiments to Earth, and to control the sequencing of science operations."

"The Harris RTX2010 processor has been selected for the DPU boards, because it has a very low power consumption. This space qualified, radiation hardened 16 bit processor has such features that make it possible to provide the complicated functions that CDMS has to perform. It is a stack based FORTH oriented processor. All the software components have been written in FORTH language with its exotic and challenging instruction set. CDMS is a real-time controller and data acquisition system and it has to process tasks in parallel. Consequently, a pre-emptive, real-time multi-tasking, operating system has been developed to run application tasks and all the required functions in parallel. All the parts of CDMS on-board software are specifically developed for this project. Unfortunately, there was no development environment for this type of processor on the market for creating real-time systems so first of all we had to create our own cross development platform. Our operating system provides system calls for using all of the hardware components and many features to make the application tasks more efficient."

[1] http://www.sgf.hu/pr-rosetta-cdms.html

[2]https://www.researchgate.net/publication/234265387_Embedded_...

> Rather instructions were bit encoded in a single memory cell so some could be executed in parallel.

I think you might be remembering the later Seaforth/Greenarrays MISC (minimal instruction set computer) chips (they may have had some similar predecessors) that did that funny encoding. The RTX2010 was more like the Novix and had a 16 bit instruction word. See:

https://users.ece.cmu.edu/~koopman/stack_computers/sec4_5.ht...

That book has good coverage of the Forth chips of that era. This undergraduate thesis has some later developments:

http://fpgacpu.ca/stack/Second-Generation_Stack_Computer_Arc...

Related stuff from same site: http://fpgacpu.ca/stack

I am referring to this feature:

4.4.4 Architectural features <snip> The NC4016 allows combining nonconflicting sequential operations into the same instruction. For example, a value can be fetched from memory and added to the top stack element using the sequence @ + in a Forth program. These operations can be combined into a single instruction on the NC4016.

Stack machines also tend to have better code density than register or memory machines, and code space is almost always at a huge premium on spacecraft. The high code density is because most instructions have all arguments implicit (by stack location). The need for stack maintenance instructions like dup and swap means they tend to require more instructions for a given function than a register machine or memory machine, but the per-instruction space savings almost always more than offsets the increased instruction count.

An accumulator machine can be thought of as half way between a register/memory machine and a stack machine, where most instructions have an implicit argument (the accumulator) and an explicit argument. This typically means code density somewhere between a stack machine and a register machine, with very little penalty in terms of instruction count. The main downside of an accumulator machine is the accumulator almost always introduces a dependency between adjacent instructions, making performant superscalar implementations more difficult. IIRC, examples of accumulator machines include V8's current internal bytecode and the old Apple II SWEET16 VM.

Before I left SV (and consequently, US) I consulted for a startup focusing on hard-realtime control systems. I found out that Forth is widely used in multiple embedded domains but unlike most popular programming languages this usage is not advertised (or deliberately kept secret even) since the language is considered to be a competitive-edge powerhouse.

It wasn't space-related but it was definitely mission-critical ... In the mid to late '90s we ran quite a few systems that handled stock trading information that were written in PolyFORTH.

Reply on news.ycombinator.com