---

This is the official website for “The ϕ System”. Its documentation and source code are based on a superset of 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 2.October.2026.

“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 ②ⓐ Application Software and ②ⓑ System Software. ②ⓐ 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 decades, 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. I waited over a period of many years 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 prosperity. 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 of the parts together. I have often heard it said that complex systems should be designed from the top-down. But to use the build-test repeat cycle to work, they must 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 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 small as one byte long or as long as 19 bytes. ϕEngine goes further than any other processor family to maximize its use of byte-addressability. This is reflected in its register files. Integer data types are multiples of a byte in size while floating point data types are multiples of two bytes in size. ϕEngine follows the IEEE-754 Floating Point Standard and interpolates several formats that are not in the standard.

ϕEngine extensively uses Status Flags to preserve the states that reflect the results of operations performed on the data types that it supports. Some main stream processors (such as RISC-V) almost totally lack them. Instructions that use them use one system for integers and another system for floating point formats that was tacked on as an after-thought. ϕEngine consistently uses the same system for integer and floating point operations. The same instructions that make use of them (such as branch on condition or produce integer value reflecting condition) are good for both. Four Flag Sets are immediately available for scalar operations that use them. This reduces dependency between instructions and encourages out of order execution. Also, moves generally don't alter flags by default. This eliminates the problem in the 68K where setting up some registers to make use of flags that were generated from an earlier test can destroy the flags before you need to use them.

ϕVec brings SIMD processing capability to ϕEngine. Vector segments up to 128-bytes (1024-bits) in length for integers or 256-bytes (2048-bits) for floating point values can be processed in parallel. Main stream processors do not use the same computing model for scalars and vectors where flags are concerned. ϕEngine does. The compare and branch instructions that are so important for scalar operations in RISC-V are useless for processing vectors. Here again, ϕEngine uses the same system by providing one flag set for every element (pair) in its vector operations. It is a very powerful system for implementing branchless processing using its multitude of data types.

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 Process 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 Sequential Access (SA). DMM uses the processor's Address Registers to directly access (via memory mapping) those parts of a space that are associated with a Chapter Number which is part of the Address Registers. SA provides sequential access to a space using a Handle with an implied pointer that is maintained by the hardware and operating system. This follows a model that is very much like fread, fwrite, fseek and ftell functions in the C I/O library. Though system calls are required to set them up, these two methods share a framework that provide processes access to I/O without system call overhead or redundant data buffers. The Chapter and Handle Sizes are 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 with x86 processor hardware.

ϕPPL

ϕPPL stands for ϕ Parallel Programming Language. It is a compiled procedural programming language and shares many features with C. Of primary importance was to fix the many flaws in C. But its scope went far beyond that. I was careful not to throw away the good features of C and wanted to even enhance them. ϕPPL is even closer to the hardware than C was ever intended to be. It supports operating system features for use 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 paradigm that is supported in all parts of The ϕ System.

ϕ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. 

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 languages. 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.

Arrays are constructed using row-major-order as in C. Most operators are automatically extended to support the SIMD model using vectors and arrays with no additional syntax overhead. For example, arithmetic operators like ‘+’ for addition will do element-wise operations on vectors and arrays with matching dimensions and counts.

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 Argument 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 by applying the mid-dot symbol ‘·’ to their type names instead of the double colon (in definition) or the period ‘.’ (when used) as in C++. Argument Overloading is not supported as with functions. This eliminates the need for so called "class browsers" to understand what functions are actually being used. Inheritance and all of its complications is not supported because it is not needed. Syntax should make it clear what is happening with the hierarchical nesting of records.

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. Also, when a function or method has no arguments, you just leave the parentheses empty. That means that the function has no arguments. You don't have to declare it with a void as you have to in C.

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 new 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 live along side of legacy network protocols which will likely never go away. But it will greatly simplify communication between trusted systems that are within the ϕ system environment. This is where ϕBus comes into play.

©2026, technoventure, inc.