On Wed, Jun 26, 2024 at 11:10:38AM -0400, Paul Koning wrote:
>
>
> > 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.
Absolutely, also on mainstream targets you could think of 128-bit integers
or long doubles which typically don't fit in (single) GPRs. I should
definitely add error handling for this. Similar, I don't error out for
non-primitive data types.
I will give register pairs a try.
Thanks for all your comments so far :)
Cheers,
Stefan
