Our initial target markets are those where programs would either be running on the bare metal (the basic program instructions running right on the cores, like an embedded system) or at most a pretty basic RTOS. From the bare metal standpoint, we can still have memory segmentation just like any other system... I would say it is even easier for the compiler to do that on our system due to the fact that all of the physical memory addresses are part of a single global memory map.
So the target market is .. high mips/watt microcontroller or DSP?
If you have fully software managed memory it sounds like any binary running on the system has full access to any other memory? This is kind of the opposite of ARM "TrustZone".
Edit: I'm just asking these questions because novel architectures tend to sink without trace and the small-system world is currently dominated by ARM. You need a real "wow" factor to get people to change their tooling.
Our focus has been on floating point performance. Originally we were targeting high performance computing, but have since expanded to high end DSP applications (Think mobile base station processing for LTE-Advanced and "5G").
For memory protection, the most traditional way would be leaving it up to a RTOS or microkernel. Something very small and verifiably secure like seL4 is something we want to port.
We have not made it a huge priority to start of with as our customers have a small number of applications that are being ported and are isolated on the system. As each application needs to be recompiled for our architecture, we think that memory segmentation done at compile time is good enough to start with (in these limited cases).
This is going to be interesting from a security point of view. It also sounds like users will need a new OS to take advantage of this?