On 12/18/2014 10:58 PM, Matthew Fortune wrote:
> David Daney <ddaney.cavm@xxxxxxxxx> writes:
>> On 12/18/2014 01:04 PM, Matthew Fortune wrote:
>>>> On Thu, Dec 18, 2014 at 10:50:27AM -0800, David Daney wrote:
>>>>
>>>>> On 12/18/2014 07:09 AM, Markos Chandras wrote:
>>>>>> 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"
>>>>>> 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.
>>>
>>>> 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.
>>>
>>> So, all this patch does is highlight that magic assembler macros have
>>> been hiding this issue since micromips was added.
>>>
>>> >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
