Discussion:
max_operands for AVR after rev 40170
(too old to reply)
Christo Crause
2018-11-02 10:06:34 UTC
Permalink
I've noted that r.40170 defines MAX_OPTS_2 for AVR in aoptutils.pas. Should
the constant max_operands in avr/cpubase.pas not also be changed to 2 to
be internally consistent? If so then I can adapt avr/raavr.pas to be
consistent with a maximum number of operands of 2.
Pierre Muller
2018-11-02 10:51:18 UTC
Permalink
I've noted that r.40170 defines MAX_OPTS_2 for AVR in aoptutils.pas. Should the constant  max_operands in avr/cpubase.pas not also be changed to 2 to be internally consistent?  If so then I can adapt avr/raavr.pas to be consistent with a maximum number of operands of 2.
Hi Christo,

I simply checked the value of maxops constant for the different CPUs:

$ grep -iw maxops */*pas
aarch64/aoptcpub.pas: MaxOps = 4;
arm/aoptcpub.pas: MaxOps = 4;
avr/aoptcpub.pas: MaxOps = 2;
i386/aoptcpub.pas: MaxOps = 3;
i8086/aoptcpub.pas: MaxOps = 3;
jvm/aoptcpub.pas: MaxOps = 2;
m68k/aoptcpub.pas: MaxOps = 3;
mips/aoptcpub.pas: MaxOps = 3;
powerpc/aoptcpub.pas: MaxOps = 5;
powerpc64/aoptcpub.pas: MaxOps = 5;
riscv32/aoptcpub.pas: MaxOps = 5;
riscv64/aoptcpub.pas: MaxOps = 5;
sparcgen/aoptcpub.pas: MaxOps = 3;
x86_64/aoptcpub.pas: MaxOps = 3;

As I found only avr and jvm having a value of 2,
I defined the macro MAX_OPTS_2 (which by the way should rather be renamed MAX_OPS_2...)

max_operands seems to be ddeclared in cpubase units:
$ grep -i "max_operands *=" */*pas
aarch64/cpubase.pas: max_operands = 6;
arm/cpubase.pas: max_operands = 6;
avr/cpubase.pas: max_operands = 4;
jvm/cpubase.pas: max_operands = 2;
llvm/llvmbase.pas: max_operands = ((-ord(cpubase.max_operands<=7)) and 7) or ((-ord(cpubase.max_operands>7)) and cpubase.max_operands);
m68k/cpubase.pas: max_operands = 4;
mips/cpubase.pas: max_operands = 4;
powerpc/cpubase.pas: max_operands = 5;
powerpc64/cpubase.pas: max_operands = 5;
riscv32/cpubase.pas: max_operands = 5;
riscv64/cpubase.pas: max_operands = 5;
sparcgen/cpubase.pas: max_operands = 3;
x86/cpubase.pas: max_operands = 4;

But you can see that the numbers are quite different...
aarch64: 6/4!
arm: 6/4!
i386 4/3 (the 4 is common to i386,x86_64 and i8086 from x86/cpubase unit)
i8086 4/3, as for i386
jvm 2/2, OK!!
m68k 4/3
mips 4/3
powerpc 5/5, OK!!
powerpc64 5/5, OK!!
riscv32 5/5, OK!!
riscv64 5/5, OK!!
sparcgen 3/3, OK!!
x86_64 4/3, as for i386

Hopefully someone else can explain that discrepancy,
I have no idea why this exists,
it might be simply related to the CPU instructions
with most parameters that are considered for optimization!

Pierre


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cg
Christo Crause
2018-11-03 06:31:21 UTC
Permalink
Post by Pierre Muller
Hopefully someone else can explain that discrepancy,
I have no idea why this exists,
it might be simply related to the CPU instructions
with most parameters that are considered for optimization!
Thanks for the backgroup Pierre. I've changed max_operands = 2 for AVR
(and updated AVRInstrConstraint in raavr.pas), recompiled the crossavr
compiler and RTL for avr5 and preliminary inspection show correct code
being generated. Perhaps these two constants (MaxOps and ax_operands)
should be merged if there isn't a difference in meaning and use case
between them?
Christo Crause
2018-11-05 08:48:17 UTC
Permalink
Post by Christo Crause
Post by Pierre Muller
Hopefully someone else can explain that discrepancy,
I have no idea why this exists,
it might be simply related to the CPU instructions
with most parameters that are considered for optimization!
Thanks for the backgroup Pierre. I've changed max_operands = 2 for AVR
(and updated AVRInstrConstraint in raavr.pas), recompiled the crossavr
compiler and RTL for avr5 and preliminary inspection show correct code
being generated. Perhaps these two constants (MaxOps and ax_operands)
should be merged if there isn't a difference in meaning and use case
between them?
I noticed that Florian removed MaxOps over the weekend. Quick action,
thank you.

Loading...