[libre-riscv-dev] system call (sc) LEV "reserved field"

[Benjamin Herrenschmidt]

On Fri, 2020-07-24 at 17:53 +0100, Luke Kenneth Casson Leighton wrote:
> 
> a low-grade version of JIT translation, which is one solution. 
> expensive, but a solution.
> 
> although i have to ask why, for Embedded, they did not just recompile
> the source code, customised for that enduser application.

Because the distinction between "embedded" and "unix" is very blurry
and in many areas obsolete.

One can compile a single image that is meant to run on a wide variety
of system and even the "embedded" world wants that capability. Either
because they end up running some kind of "upstream" OS image, or
because they don't want to maintain completely different SW images for
all their products, etc...

> however this also actually illustrates precisely why i mentioned that
> for best results, a spec has to have different platform behaviour for
> Embedded as completely separate and distinct from UNIX.

This is not really true anymore. For example, do you consider your cell
phone or your TV "embedded" or "unix" ? They are both running Linux
after all...

> the rules for Embedded in RISCV state that traps are *not* needed for
> illegal instructions (it is up to an implementor to decide if they
> wish to add them).  the Conformance Test Suite does *not* test for
> illegal instructions.
> 
> this on the basis that Embedded Markets are typically one-off
> deployment, where the toolchain and all build source is "snapshotted"
> at product release time, used internally and the source code and
> toolchain almost never see the light of day.  mainline upgrades are
> exceptionally rare.

There are quite a few counter examples even in the "embedded" market.
Especially when it comes to storage appliances. Some of these things
can even run CentOS.

> examples include Trinamic Stepper ASICs, which actually hit the
> shelves even before RISCV Standardisation was ratified.
> 
> the binaries are in ROM.  whatever trap spec incompatibility with
> "Latest and Greatest" are utterly irrelevant for them and their
> customers.
> 
> 
> so in that context, i am slightly confused to hear that for Freescale
> *Embedded* processors that there is even a binary incompatibility
> problem with lwsync *at all*.
> 
> if you have time i'd love to hear more, what's the story there?

I forgot the details, but a specific core variant from FSL screwed up
the decode table and would trap on lwsync instead of ignoring the bit.

> > > but because the bit is ignored, there is no way that can be done.
> > 
> > But that's fine because "sync" is a strict superset so ignoring the
> > bit
> > works just fine.
> 
> in this case, yes.
> 
>  
> > > so whilst on the face of it, lwsync *sounds* like a
> > counterexample,
> > > instead (caveat, i do not know what FSL is), it seems more to
> > support
> > > the case *for* use of reserved bits raising illegal instructions
> > [on
> > > UNIX platforms]
> > 
> > I fail to follow your logic. The trap case is a complete non-
> > starter
> > for an instruction meant to be a lightweight memory barrier. 
> 
> ok given that it is a "hint" type and not quite suited to "reserved"
> we are now at cross purposes.
>  
> and, also, it is a special case that happens to gave, as one of its
> requirements, to be "lightweight" in order to be useful.
> 
> > The
> > transparent "fallback" to a full memory barrier on the contrary
> > works
> > fine. There is never any case where "trapping an emulating" is the
> > desired behaviour.
> 
> indeed... in this very special case that we have established, by it
> effectively being a "hint", falls completely outside of what i am
> concerned about

In *most* cases trap + emulation leads to unusable performances though.

Ben.