[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=238

--- Comment #49 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #47)

> On 11/21/20, Alexandre Oliva <oliva at gnu.org> wrote:

> > One is how to mark fragments of code so that the tooling can tell
> > whether to emit or decode 16-bit or 32-bit instructions.  Say, how is
> > the disassembler supposed to tell whether it's looking at a 32-bit
> > instruction or a pair of 16-bit instructions?

we have identified no less than *three* places where "hidden state" completely
changes the meaning of instructions in OpenPOWER ISA, already.

what we are doing is really no different although it is not so common to change
state during a function call.

these are (so far identified):

* LE/BE mode
* 32/64 mode
* FP Accuracy mode

whilst the two first ones tend to be on a per-program basis, the last one
definitely is not.  this is specifically intended to be used to get FP hardware
to "speed up" by returning a less-accurate answer when accuracy is not critical
to the application.

clearly a given function can in NO WAY be left in this mode so it is set, the
instruction called, and the relevant FPSPR bit reset.

that gcc, llvm and binutils have no idea that this FP mode even exists is not
IBM's problem.

given that the precedent exists we are exploiting that, admittedly to an extent
that is unprecedented in the history of computing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.