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.
Just one thing to note: this is not a novel feature but pretty similar
to Rust's explicit register operands:
https://doc.rust-lang.org/rust-by-example/unsafe/asm.html#explicit-register-operands
Cheers,
Stefan
