On 12/18/2014 10:58 PM, Matthew Fortune wrote:

David Daney [off-list ref] writes:

quoted

On 12/18/2014 01:04 PM, Matthew Fortune wrote:

quoted

quoted

On Thu, Dec 18, 2014 at 10:50:27AM -0800, David Daney wrote:

quoted

On 12/18/2014 07:09 AM, Markos Chandras wrote:

quoted

MIPS R6 changed the opcodes for LL/SC instructions and reduced the
offset field to 9-bits. This has some undesired effects with the

"m"

quoted

quoted

quoted

quoted

constrain since it implies a 16-bit immediate. As a result of
which, add a register ("r") constrain as well to make sure the
entire address is loaded to a register before the LL/SC operations.
Also use macro to set the appropriate ISA for the asm blocks

Has support for MIPS R6 been added to GCC?

If so, that should include a proper constraint to be used with the
new offset restrictions.  We should probably use that, instead of
forcing to a "r" constraint.

In a non-public earlier discussion I've requested the same but
somehow that was ignored.

I must have missed that comment or not been on the thread.

quoted

We need suitable constraints or the alternatives will be very, very
ugly.

We can certainly discuss and investigate such things but there is a
general problem of a growing list of different size displacement
fields in load/store instructions. Obviously you could just opt to
keep things the way they are for uMIPS today and leave the assembler
to expand the instruction but my opinion is that magic expanding
assembler macros are infuriating. We have however had to put support
in binutils for many of them, simply to keep enough software building

to ease the transition.

quoted

So, all this patch does is highlight that magic assembler macros have
been hiding this issue since micromips was added.

quoted

From your experiences will people invest the effort to look at the

size of a displacement field for all the memory operations in an
inline asm block and then choose an appropriate memory constraint?

I'm obviously wary of putting things into GCC that are either only
used in a handful of places (or not at all). The alternative to
constraints is of course to try and reduce the need for inline asm and
offer builtins for specific instructions or more complex operations.

Well, GCC directly emits LL/SC as part of its built-in support for
atomic operations, so the knowledge of the constraints for the
instructions must be present there.  Since the constraints must be
present in GCC, using them in the kernel shouldn't be a problem.

Yes you are right I thought this particular case only had constraints
for the immediate and not the whole memory operand, I'm suffering from
too many tasks and too little time. Several of the memory constraints are
marked as internal and I'm not sure if that means they are unsafe to use
from inline asm or just not deemed important.

The memory constraint that LL and SC need is 'ZC'. I don't believe this
is documented so you will have to trust that its meaning will not change
but I can give some assurance of that since I will review all MIPS GCC
changes.

Obviously to use anything other than the 'm' constraint you are going
to need to know when any given constraint was added to GCC.
'ZC' was only added to GCC in March 2013 r196828 which I believe it is a
GCC 4.9 feature so you will have to use it conditionally if you use it at
all.

is this something desirable? check the gcc version, initialize a macro
and then use that macro as a constrain? i haven't thought this through,
but it could be a bit messy.

-- 
markos