> On Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus
> <stefa...@linux.ibm.com> wrote:
>
> On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote:
>>
>>
>>> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
>>> <stefa...@linux.ibm.com> wrote:
>>>
>>> On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
>>>>
>>>>>>> ...
>>>>>>> could be rewritten into
>>>>>>>
>>>>>>> int test (int x, int y)
>>>>>>> {
>>>>>>> asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y));
>>>>>>> return x;
>>>>>>> }
>>>>
>>>> I like this idea but I'm wondering: regular constraints specify what sort
>>>> of value is needed, for example an int vs. a short int vs. a float. The
>>>> notation you've shown doesn't seem to have that aspect.
>>>
>>> As Maciej already pointed out the type of the expression should suffice.
>>> My assumption was that an asm can deal with a value as is or its
>>> promoted value. At least for integer values this should be fine and
>>> AFAICS is also the case for simple constraints like "r" which do not
>>> define any mode. I've probably overseen something but which constraint
>>> differentiates between int vs short? However, you have a good point
>>> with this and I should test this more.
>>
>> I thought there was but I may be confused. On the other hand, there
>> definitely are (machine dependent) constraints that distinguish, say, float
>> from integer registers; pdp11 is an example. If you were to use an "a"
>> constraint, that means a floating point register and the compiler will
>> detect attempts to pass non-float operands ("Inconsistent operand
>> constraints...").
>>
>> I see that the existing "register int ..." syntax appears to check that the
>> register is the right type for the data type given for it, so for example on
>> pdp11,
>>
>> register int ac1 asm ("ac1") = i;
>>
>> fails ("register ... isn't suitable for data type"). I assume your new
>> syntax would perform the same check and produce roughly the same error
>> message. You might verify that. On pdp11, trying to use, for example, "r0"
>> for a float, or "ac0" for an int, would produce that error.
>
> Right, so far I don't error out here which I will change. It basically
> results in bit casting floats to ints currently.
That would be bad. For one thing, a PDP11 float doesn't fit in an integer
register.
That also brings up another point (which applies to more mainstream targets as
well): for data types that require multiple registers, say a register pair for
a double length value, how is that handled? One possible answer is to reject
that. Another would be to load a register pair.
This case applies to a "long int" on pdp11, or 32 bit MIPS, and probably a
bunch of others.
paul
