Supporting reconfigurable ALUs. Xputers in general do not have an instruction sequencer. A data sequencer is used instead , , , which operates in a strictly procedural way (in contrast to the well-known "data flow machines" which are data-driven by arbitration). This supports the use of reconfigurable datapaths (rDPs, such as e.g. reconfigurable ALUs: rALUs , , ). Because of its very tight coupling between instruction sequencer and ALU the (control-procedural) von Neumann paradigm does not support the use of rDPs.
All "Compilers" for Xputers generate H/S images. Due to Xputers' basic structure and operation principles a compiler for Xputers always has to generate two kinds of machine code: (1) sequential code to program the data sequencer (a kind of software code), and (2) reconfiguration code to set up application-specific data paths (configured hardware) within the rDP platform. That¹s why during compilation of Xputer code from a problem expressed in a high level programming language (like X-C , , , which is an extension of C) always a partitioning problem has to be solved, corresponding to that in any hardware/software co-design. From this point of view the data sequencer architecture comprises a particular hardware/software interface platform.
Xputer use for acceleration. Especially for algorithms with regular or semi-regular data dependencies the Xputer paradigm is much more efficient than the von Neumann paradigm. This has been proven experimentally , . Also the mechanisms providing this efficiency have been studied . Reasons for the Xputer¹s advantage over the von Neumann paradigm are: (A) some overhead artefacts executable only at run time (von Neumann bottlenecks) can be pushed over to compile time - only when Xputers are used, (B) a good rDP platform supports parallelism at data path level, (C) compilation techniques for configuring intra-rDP pipelines are feasible, (D) most Xputer architectures provide several data sequencers usable in parallel which gives further support of intra-rDP parallelism, (E) the Xputer paradigm supports interleaved memory use because its compilation methods comprise better methods to find good storage schemes.
H/S Codesign to Supercomputing Interface. So, because of (E) it is believed, that the Xputer paradigm is a promising opportunity of cross fertilization between hardware/software co-design and supercomputing .
Universality of the Xputer Paradigm. The Xputer paradigm is as universal as the von Neumann paradigm. In contrast to "data flow machines" not being check point traceable since operating indeterministically, Xputers are commercializable. A very wide variety of Xputer architectures may be developed. Several Xputer architectures MoM-1 thru MoM-3 have been developed at Kaiserslautern University , , ,  supporting two-dimensional memory organization and multiple data sequencer parallel usage. By implementing an escape mechanism, which enables data-driven scan-patterns , Xputers can also implement applications, which feature branches in the control flow in the von Neumann realization.
H/S codesign as an ASIC design approach - Xputer-based. By retargeting the rDP and using data sequencers from a cell library an ASIC may be derived from any Xputer application implementation. This way ASIC design is the result of a kind of hardware/software co-design approach . In such cases a stand-alone use of the Xputer may be desirable to minimize chip count. Such a stand-alone use is feasible, since the Xputer paradigm is as universal as the von Neumann paradigm .
Partitioning of partitions - Codesign in Codesign. Because of the non-von-Neumann property of the paradigm large amounts of traditional software cannot be adapted with reasonable effort to run on Xputers, unless an automatic cross compilation method is available. So in many application environments it might be not reasonable to run Xputers in stand-alone mode. In such cases it is recommended to use Xputers as accelerating co-processors together with von Neumann hosts, such as e.g. as an extension to a work station. In this case the hardware/software co-design approach turns into a two stage process  including: (1) software partitioning into a von Neumann part and an Xputer part, and (2) partitioning of the Xputer software into the procedural part and the structural part.