One of the characteristics of “Problem-Oriented Languages” (POL) is that they are tiny. The language run-time provides just enough to enable a programmer to extend the language into something appropriate to the needs and terminology of the domain. This “tininess” also extends to memory usage. On a single process system the complete language and operating …
In my continuing research for my bare-metal operating system and language, I have been looking at polyFORTH. This is a system language designed for use on the massively-parallel processor chips produced by GreenArrays, obviously from the same heritage as the Problem Oriented Language philosophy from Charles Moore’s 1970 document. One interesting thing about the polyFORTH …
Continue reading ‘Memory map thoughts for a bare-metal system’ »
As you may recall, if you have read a few of these blogs, ELIUS is the name I am using for the stack-based “problem-oriented language” (POL) which I plan to include as a system language for the bare-metal operating system I am building for the Raspberry Pi. Charles Moore’s POL concept, and languages based on …
Forth, and similar languages inspired by Charles Moore’s approach to software have evolved in a particular direction. Like Donna Noble in “The Doctor’s Daughter”, FORTH is “good with numbers”, but traditionally very limited in its string processing abilities. In Programming A Problem-Oriented-Language (POL), Moore writes: What can you do with a character string? I’ve only …
I have been reading about the early days of FORTH recently, and learned a lot about the ideas and philosophy behind the language and the system. In the past, when I had tried to create my own FORTH-style languages I think I was missing something important. I had been confusing the “language” of available FORTH …