---

This is the official website for “The ϕ System”. Its documentation and source code are based on Unicode. ϕ uses many of its characters to serve specific purposes. To view them in the way they are intended, you will need to install the font file PhiBASIC.ttf. You can download the file here. The last update was on 1.July.2025.

“The ϕ System” (or just ϕ for short) is a computer platform consisting of a co-designed ① Processor family (ϕEngine), ② Programming Language (ϕPPL) and ③ Operating System (ϕOS). The three share many features that can't just be tacked on to a mainstream platform. They require pouring a new foundation.

Why “The ϕ System”?

Computers are composed of many parts. Those parts require people with broad skill sets to develop, manufacture, promote, manage and use them effectively. Computers are so complex that no one person or even company can ever hope to fully understand how their various parts work together. And since different people have conflicting priorities, it is a wonder that we have working computers at all. The key to building complex systems is modular design. Modules have interfaces that are agreed upon by those who design the parts to work together as a system.

At the macro level, computers are divided into two parts. These are ① Hardware and ② Software. By its very nature, hardware must exist before software can do anything. But software can also roughly be divided into two kinds. These are ②a Application Software and ②b System Software. ②a is certainly the most important because it is the main reason why anyone would want a computer in the first place. But, as the industry has learned over the years, application software requires services that are shared with all other application software that you might want to run on a computer. That is where system software comes in. And even though application software is more important, design of system software is generally more difficult. A good OS designer should have many years of writing applications before he can have any hope of designing and writing a quality operating system. Application software can't run effectively without the presence of system software just as you can't have any software without hardware to run it on. Computers are layered with ①Hardware on the bottom, ②System Software in the middle and ③Application Software on top. If you remove any of them, the whole system won't do very much for you. They have to be designed and built to work together.

Computers are made of inter-dependent parts. One part can have features that are not used by another part. But the parts that are needed must be all present in a coordinated fashion or the system as a whole will not do its job. As in nature, if a feature that is present in one part of the system is not used by the rest of the system, it is often eliminated over time. As the expression goes “If you don't use it, you lose it”. Like a blind cave salamander, if it doesn't use its eyes for lack of light, they have a tendency to degenerate. Such was the case for many of the advanced features of CISC processors back in the 1980's. When high-level programming languages failed to use them, other groups of people with different priorities came along promoting RISC and the advanced features were stripped away. We were left with blind salamanders that are unable to use their eyes. But blind salamanders still have arms, legs and other senses which make them able to get around and make a living in the dark without their eyes. This is how RISC processors prosper. They are like the billions of trilobites that filled up the fossil deposits during the Cambrian explosion. They are primitive but they are cheap. They are thriving. And they are now filling up our land fills just like trilobites did in the distant past. Don't get me wrong. RISC processors are great for use in dedicated smart devices. But they make terrible general-purpose computers.

There are those of us who believe that eyes are very valuable assets. We resent others who choose to blind us so that we can be locked into their way of doing things. Back in the 1980's I found such CISC features as flags very useful and became dependent upon them for doing such things as detecting overflows. I would often read that managers of companies would mandate that their programmers were not allowed to write any code in assembly language. Assembly is what you have to do to make use of features that are in the hardware but not supported by what I call crippled high-level languages. We all know that some managers tend to be simple-minded and run their shops and companies by rules of thumb that I sometimes like to call “Nursery Rhymes”. They bear some of the blame for the elimination of advanced features in CISC processors. Over the years I kept waiting for an good HLL to come around that would let me reach those advanced features. But none ever came. Instead, the minimalists won out and I would now have to program while wearing a straight jacket if I ever had a development host based on something like RISC-V.

These lessons of the past show you that advanced features in one part of a system must be supported in the other parts or they may not happen at all. This is what is meant when someone says that something was designed for “the least common denominator”. The result is like having to drive a stripped down vehicle that provides you with enough to get by but never do its job well. That is survival, not prospering. Over the years I have been building a list of what I would want to see in the computers I use every day. Many of these will never happen unless all of the system's parts are co-designed to work together.  Putting features in one part that are not supported in the rest of the system means that they will never get used and will likely just go away. The only possible way to bring many advanced features into reality is to design all the parts together. I have often heard it said that complex systems should be designed from the top-down but they should be built from the bottom-up. That is because the bottom must be there before anything above it can do anything at all. Modular design lets you do that. The bottom-most layers can be built and tested in isolation with the proper tools. Processors are expensive to build. ASICs typically cost millions of dollars to make. But now we have FPGAs. They are becoming cheaper to make and easier to program. I think that ϕEngine's time has come.

Said in the simplest way, “The ϕ System” is a co-design of processor ISA (ϕEngine), programming language (ϕPPL) and operating system (ϕOS) that all work together. Co-design can bring a combination of advanced and legacy functionality into usable reality. I think it is the only way. Below I discuss each of these parts in more detail.

ϕEngine

ϕEngine is a processor ISA (Instruction Set Architecture) family with both 32-bit (ϕEng32) and 64-bit (ϕEng64) sub-architectures. Rather than having two different instruction encodings, they share the same programmer model and the same encodings. Their behavior only differs as a direct or indirect consequence of the size of their their Address Registers. They are CISC processors with RISC-like features but with a variable-length instruction size. They have byte-addressable memories with little-endian byte order. Instructions can be as little as one byte long and are multiples of a byte in length. ϕEngine goes further than any other processor family to maximize its use of byte addressability by extending this feature into its register files. Integer values are multiples of a byte in size while floating point values are multiples of two bytes in size. ϕEngine follows the IEEE-754 Floating Point Standard and interpolates several formats that are not present in the standard. ϕSemiVec provides SIMD processing capabilities. Vector segments up to 128-bytes (1024-bits) in width for integers or 256-bytes (2048-bits) for floating point values can be processed in parallel.

One of ϕEngine's most powerful features is its support for multiple spaces for each process. It is called an MPA which stands for Multi-Space Processor Architecture. Two mechanisms are provided to make multiple spaces accessible to each process. One is for Direct Memory Mapping (DMM) and the other is for Direct Sequential Access (DSA). DMM uses the processor's Address Registers to directly access (via memory mapping) those parts of a space that are associated with a Handle. DSA provides sequential access to a space using a pointer that is maintained by the hardware and operating system. Though system calls are required to set them up, these two methods share a framework that provides processes ways to do their I/O without system call overhead. The Handle Size is 8-bits for ϕEng32 and 16-bits for ϕEng64.

ϕSim is a simulator that is being developed to simulate the executable features of ϕEngine. It runs on MS Windows over x86 processor hardware.

ϕPPL

ϕPPL stands for ϕ Parallel Programming Language. It is a compiled procedural programming language that is intended to be the next step in programming language evolution beyond C with which it shares many features. It is even closer to the hardware than C was ever intended to be. But it also has many high-level features that C lacks. It supports operating system features to be used in ϕOS which is co-designed for the purpose. ϕPPL will be used for writing operating systems, device drivers and application software in the same way C has been. But unlike C, ϕPPL is aware of the Multispace Processor Architecture that is supported in all parts of ϕ.

ϕPPL's character set is based on ϕText which is a super-set of Unicode. Source code can be in ϕText, UTF-8, UTF-16 or UTF-32. The last two are discouraged while the first one  is recommend. ϕPPL uses the processing model of C which makes it possible to link modules into the same program that were compiled separately from a mix of the two languages. However, the ϕ tool-chain uses conventions that are unique to ϕ so that any C compiler that is adapted for use in the ϕ tool chain must use the same conventions. Aside from this and a few other minor details, the calling conventions are the same as in C. But you can do more things with it in ϕPPL such as passing arrays by value as arguments to functions. 

Arrays are constructed using row-major-order and there is no required stack frame because there is no stack unwinding as is needed for the try-throw-catch exception feature in C++ and other programming langauges. This makes ϕPPL more compatible with C in its execution model. ϕPPL is not source compatible with C as it is with C++ since the syntax is quite different.

Pointers are supported but the syntax is changed to be more natural and understandable. Additional constructs are supported in the typing system to make pointer usage and array indexing safer than they are in C.

Function overloading is not supported. This eliminates the name-mangling that makes C++ so difficult to work with in assembly language. Operator Overloading is not needed because New Operator Definition is much better. It allows you to assign Unicode symbols to user-defined operators. Using Unicode characters that don't otherwise mean anything in the syntax lets you retain existing operators so that you don't have to lose one operator to gain another. Using symbols that aren't in ϕPPL's basic syntax means that source code doesn't become ambiguous as when an apparent operation no longer means what is appears to mean in C++.

ϕPPL's control structures are more elaborate and full-featured than C's. The if..else structure is pretty much unchanged. ϕPPL organizes looping control into a much more modular syntax that gives you more control and more options. The functionality of the while and for constructs of C are integrated into this modular system. The switch..case control structure is expanded to support more data types but is still much the same as in C. goto is supported but target labels must begin with one of the Charm Characters.

Objects and their methods are supported but with a more versatile syntax that doesn't require values to be heterogeneous compound data types. Methods are designated with the mid-dot symbol ‘·’ instead of the double colon (in definition) or the period ‘.’ (when used) as in C++. Argument Overloading is not supported. This eliminates the need for so called "class browsers" to understand what functions are actually being used. Nested Object Inheritance is supported.

A new scope called "Equate" is created. It eliminates most of the need for a pre-processor and adds type checking where simple string substitution falls short. This scope is not only used for data but also for functions to support compile-time computation of values that do not have run-time storage requirements. You can't take the address of an equate because they don't exist in run-time memory.

ϕPPL is IEEE-754 aware. It supports special values like Nil (‘⊙’) and Infinity (‘∞’) and defines special symbols to represent their values. Void is used as in C but it is represented with the symbol ‘⍉’ instead of a key word. Values of the two integer classes num and int support nil values.

One of ϕPPL's most powerful features is in its rich set of operators. Not only are there more of them (such as Max ‘⤒’ and Min ‘⤓’) but most are automatically extended for element pair-wise operation between static arrays with compatible dimensional structure. Several assignment operators are defined to support more than simple writes to destination variables. A full set of compare operators are represented by the Unicode symbols traditionally used for them in print such as ‘≠’ for not equal, ‘≥’ for greater or equal and ‘≤’ for less or equal.

ϕOS

Any efficient implementation of ϕEngine's unique capabilities requires an operating system. That is what ϕOS is all about. It will be written in ϕPPL which is expressly designed to enable its capabilities. My ideas on operating system design came early. But it will likely be the last working piece of the puzzle because of its dependence on using ϕPPL to build it and ϕEngine to execute it. Applications written in ϕPPL could be developed and tested using ϕSim long before we have actual hardware to run ϕOS on.

One of ϕOS's unique features is in its ability to do Object-Oriented operations at a file level. One read-only executable file can be paired with one or more read-write files to make high-level objects. These will be constructed differently for processes and other objects that can be set up and ready for calling as a service. This system greatly simplifies and standardizes inter-process communication by eliminating the need for complex network protocols. The improved architecture will still support legacy network protocols which will likely never go away for security reasons. But it will greatly simplify communication between trusted systems that are within the ϕ system environment. This is where ϕBus comes into play.

©2025, technoventure, inc.