A few years back (few being relative), when z/Architecture was first introduced, we wound up doing exactly what Dan suggests. We had one module that did a lot of data manipulation and created another module to do the same processing using 64 bit architecture.I remember dual-pathing one piece of code where a subroutine could be reduced to a handful of instructions, but that was certainly an exceptional case (and IIRC, removed the dual-pathing before putting it into production anyway).
*Mark* On Fri, Mar 22, 2024 at 12:46 PM Dan Greiner <[email protected]> wrote: > For the past few decades, much of the instruction-set-architecture (ISA) > enhancements to Z-series processors has been driven by Java, where dynamic > code generation can immediately make use of newer instructions. One of the > frustrations in architecting newer ISA facilities is the realization that > they might not get used by non-dynamic-interpretation environments for > years. It was my understanding that this lack of broad utilization is what > killed off transactional execution. > > As Peter Relson notes, it's hard to imagine many newer instructions that > warrant dual-path code, depending on whether they're installed or not. Not > only is there the overhead of branchy code, but the nuisance of testing > both paths and correctly ensuring that the paths are properly taken. > > One newer facility that might prove to be a significant benefit to older > code – and worthy of upgrade – is the vector packed-decimal facility > (introduced on the z14) and its enhancements 1 and 2 (introduced on the z15 > and z16, respectively). For packed-decimal workloads, avoiding all of the > memory accesses inherent to the Chapter 8 decimal instructions – and having > 32 128-bit registers – is a real attraction. An alternative to branchy > dual-path code might be to have separate load modules – one for the > original-recipe code and one for the extra-crispy code – that are > dynamically invoked based on the presence (or absence) of the particular > facility. >
