P.S. Follow up to my last post

P.S. Follow up to my last post

[jacob navia]

Sorry, pressed send too son.

The lack of the Ebb instructions is CRUCIAL for performance when accessing tables / arrays!
This instructions allow to combine an addition and a shift by 1, 2 or 3, to access tables of shorts, ints or doubles.
This speeds up the access to tables enormously and would allow gcc to generate much better code.

That is the motivation behind this bug report.

Re: P.S. Follow up to my last post

[Jan Beulich]

On 25.08.2023 13:52, jacob navia wrote:
> The lack of the Ebb instructions is CRUCIAL for performance when accessing tables / arrays!
> This instructions allow to combine an addition and a shift by 1, 2 or 3, to access tables of shorts, ints or doubles.
> This speeds up the access to tables enormously and would allow gcc to generate much better code.

Since you're writing to binutils@, you may want to also mention what gas
bug you think you see. So far (also in the other mail) you've talked of
only gcc. If you meant to say that like in gcc you need to enable use of
the instructions in gas, then yes, that's the way the RISC-V assembler
works (like e.g. also the PPC one, but unlike e.g. the x86 one).

Jan

Re: P.S. Follow up to my last post

[jacob navia]

OK, there is no bug, I didn’t expect anything else.

SO:

To use all the instruction of the processor he/she is running on, the user should:

1)Be aware that gcc doesn’t see crucial instructions of the processor by verifying its assembler output.

2) Be aware that there is an (undocumented) option -march… that will enable the assembler and the compiler to generate all the instructions of the current processor.

Well, there is NO BUG!

This is by design then.

Thank you very much.

Jacob



> Le 25 août 2023 à 14:00, Jan Beulich <jbeulich@suse.com> a écrit :
> 
> On 25.08.2023 13:52, jacob navia wrote:
>> The lack of the Ebb instructions is CRUCIAL for performance when accessing tables / arrays!
>> This instructions allow to combine an addition and a shift by 1, 2 or 3, to access tables of shorts, ints or doubles.
>> This speeds up the access to tables enormously and would allow gcc to generate much better code.
> 
> Since you're writing to binutils@, you may want to also mention what gas
> bug you think you see. So far (also in the other mail) you've talked of
> only gcc. If you meant to say that like in gcc you need to enable use of
> the instructions in gas, then yes, that's the way the RISC-V assembler
> works (like e.g. also the PPC one, but unlike e.g. the x86 one).
> 
> Jan

Re: P.S. Follow up to my last post

[Jan Beulich]

On 25.08.2023 15:07, jacob navia wrote:
> OK, there is no bug, I didn’t expect anything else.
> 
> SO:
> 
> To use all the instruction of the processor he/she is running on, the user should:
> 
> 1)Be aware that gcc doesn’t see crucial instructions of the processor by verifying its assembler output.
> 
> 2) Be aware that there is an (undocumented) option -march… that will enable the assembler and the compiler to generate all the instructions of the current processor.
> 
> Well, there is NO BUG!

Well, if -march= is indeed undocumented for gcc, that's something
worth reporting there then, I would say.

Jan

Re: P.S. Follow up to my last post

[Paul Koning]

> On Aug 25, 2023, at 9:30 AM, Jan Beulich via Binutils <binutils@sourceware.org> wrote:
> 
> On 25.08.2023 15:07, jacob navia wrote:
>> OK, there is no bug, I didn’t expect anything else.
>> 
>> SO:
>> 
>> To use all the instruction of the processor he/she is running on, the user should:
>> 
>> 1)Be aware that gcc doesn’t see crucial instructions of the processor by verifying its assembler output.
>> 
>> 2) Be aware that there is an (undocumented) option -march… that will enable the assembler and the compiler to generate all the instructions of the current processor.
>> 
>> Well, there is NO BUG!
> 
> Well, if -march= is indeed undocumented for gcc, that's something
> worth reporting there then, I would say.

It would be if it were true, but of course it is not.  -march is clearly mentioned in the info pages, the man pages, and in "gcc --target-help".  Likewise, it is documented in the info pages, man pages, and "as --help".

	paul

Re: P.S. Follow up to my last post

[jacob navia]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

OK

Just do nothing. It is the best solution.

The assembler doesn’t assemble instructions recognized by the machine it is running on?

The user should use the undocumented march=xxx option. And if he doesn’t read the inexistent documentation, that’s his/her fault.

Thank you very much for your attention

Jacob


> Le 28 août 2023 à 08:17, Jan Beulich <jbeulich@suse.com> a écrit :
> 
> On 25.08.2023 21:44, jacob navia wrote:
>> I am just invoking the assembler with its default settings:
>> 
>> ~/star64 $ as -o test.o test.s
>> 
>> The assembler is testing the default architecture here:
>> Function: riscv_ip
>> 
>> 	for (; insn && insn->name && strcmp(insn->name,str) == 0; insn++) {
>> #if 0
>> 		if ((insn->xlen_requirement != 0) && (xlen != insn->xlen_requirement))
>> 			continue;
>> 
>> 		if (!riscv_multi_subset_supports(&riscv_rps_as,insn->insn_class)) {
>> 			error.missing_ext = riscv_multi_subset_supports_ext(&riscv_rps_as,
>> 							    insn->insn_class);
>> 			continue;
>> 		}
>> #endif
>> 
>> The #if 0/#endif were added by me. I think those tests do not belong here. The assembler should assemble and not test if the instruction is legal. If the instruction is illegal the program will crash at run-time, something not that unusual if you are programming in assembler!
> 
> Having a program crash at runtime when this can be avoided at build time is
> deemed undesirable by many people, including me. I did point out before that
> there are two approaches for assemblers - default-enabling everything and
> default-disabling everything except the base architecture insns. To a large
> part this is a decision to be taken by the people writing an assembler. But
> there are technical constraints as well: As soon as you have two conflicting
> extensions (which RISC-V was always allowing for, and which it now actively
> has), the former model won't work very well anymore.
> 
> Of course you're free to propose a patch allowing the alternative model (via
> command line option and/or directive). Obviously whether that'll be approved
> is unknown up front.
> 
>> And if you are assembling compiler output, it is up to the compiler to furnish the correct instructions.
> 
> Yes. Plus, with an assembler following the former model, the necessary
> directives. (As an aside, compilers aren't bug-free, and hence the assembler
> still applying some sanity checks makes some sense.)
> 
>> Tiny-asm doesn’t test any instruction compliance and that is why it works out of the box!
> 
> As said, which model to use is up to the writers of any particular assembler.
> 
> Jan

Re: P.S. Follow up to my last post

[Jan Beulich]

On 25.08.2023 21:44, jacob navia wrote:
> I am just invoking the assembler with its default settings:
> 
> ~/star64 $ as -o test.o test.s
> 
> The assembler is testing the default architecture here:
> Function: riscv_ip
> 
> 	for (; insn && insn->name && strcmp(insn->name,str) == 0; insn++) {
> #if 0
> 		if ((insn->xlen_requirement != 0) && (xlen != insn->xlen_requirement))
> 			continue;
> 
> 		if (!riscv_multi_subset_supports(&riscv_rps_as,insn->insn_class)) {
> 			error.missing_ext = riscv_multi_subset_supports_ext(&riscv_rps_as,
> 							    insn->insn_class);
> 			continue;
> 		}
> #endif
> 
> The #if 0/#endif were added by me. I think those tests do not belong here. The assembler should assemble and not test if the instruction is legal. If the instruction is illegal the program will crash at run-time, something not that unusual if you are programming in assembler!

Having a program crash at runtime when this can be avoided at build time is
deemed undesirable by many people, including me. I did point out before that
there are two approaches for assemblers - default-enabling everything and
default-disabling everything except the base architecture insns. To a large
part this is a decision to be taken by the people writing an assembler. But
there are technical constraints as well: As soon as you have two conflicting
extensions (which RISC-V was always allowing for, and which it now actively
has), the former model won't work very well anymore.

Of course you're free to propose a patch allowing the alternative model (via
command line option and/or directive). Obviously whether that'll be approved
is unknown up front.

> And if you are assembling compiler output, it is up to the compiler to furnish the correct instructions.

Yes. Plus, with an assembler following the former model, the necessary
directives. (As an aside, compilers aren't bug-free, and hence the assembler
still applying some sanity checks makes some sense.)

> Tiny-asm doesn’t test any instruction compliance and that is why it works out of the box!

As said, which model to use is up to the writers of any particular assembler.

Jan

Re: P.S. Follow up to my last post

[jacob navia]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

I am just invoking the assembler with its default settings:

~/star64 $ as -o test.o test.s

The assembler is testing the default architecture here:
Function: riscv_ip

	for (; insn && insn->name && strcmp(insn->name,str) == 0; insn++) {
#if 0
		if ((insn->xlen_requirement != 0) && (xlen != insn->xlen_requirement))
			continue;

		if (!riscv_multi_subset_supports(&riscv_rps_as,insn->insn_class)) {
			error.missing_ext = riscv_multi_subset_supports_ext(&riscv_rps_as,
							    insn->insn_class);
			continue;
		}
#endif

The #if 0/#endif were added by me. I think those tests do not belong here. The assembler should assemble and not test if the instruction is legal. If the instruction is illegal the program will crash at run-time, something not that unusual if you are programming in assembler!

And if you are assembling compiler output, it is up to the compiler to furnish the correct instructions.

Tiny-asm doesn’t test any instruction compliance and that is why it works out of the box!

Jacob


> Le 25 août 2023 à 19:03, Paul Koning <paulkoning@comcast.net> a écrit :
> 
> 
> 
>> On Aug 25, 2023, at 12:10 PM, jacob navia <jacob@jacob.remcomp.fr> wrote:
>> 
>> OK.
>> 1) We agree that the -march=rv64gc_zbb option is completely undocumented and impossible for the user to know.
>> 2) We agree that « gnu gas » is an assembler whose duty is to assemble instructions. But « gas » will refuse to assemble those instructions. 
>> Why is that? It is the responsibility of the programmer or the compiler to write the instructions that are present in this or another machine. 
>> Why the assembler thinks it is necessary to forbid some instructions???
> 
> It's reasonable for the assembler to enforce ISA variations, based on what it's told in the -march switch.  If so, then (a) gcc has to pass that switch, and (b) gcc can't add a variant that gas doesn't know about.
> 
> Is that the case here?  Are you invoking the assembler manually or having it done for you by gcc?  If the former, the -march switch is your responsibility; if the latter, then gcc is responsible for getting it right.
> 
> 	paul

Re: P.S. Follow up to my last post

[Paul Koning]

> On Aug 25, 2023, at 12:10 PM, jacob navia <jacob@jacob.remcomp.fr> wrote:
> 
> OK.
> 1) We agree that the -march=rv64gc_zbb option is completely undocumented and impossible for the user to know.
> 2) We agree that « gnu gas » is an assembler whose duty is to assemble instructions. But « gas » will refuse to assemble those instructions. 
>  Why is that? It is the responsibility of the programmer or the compiler to write the instructions that are present in this or another machine. 
>  Why the assembler thinks it is necessary to forbid some instructions???

It's reasonable for the assembler to enforce ISA variations, based on what it's told in the -march switch.  If so, then (a) gcc has to pass that switch, and (b) gcc can't add a variant that gas doesn't know about.

Is that the case here?  Are you invoking the assembler manually or having it done for you by gcc?  If the former, the -march switch is your responsibility; if the latter, then gcc is responsible for getting it right.

	paul

Re: P.S. Follow up to my last post

[jacob navia]

OK.
1) We agree that the -march=rv64gc_zbb option is completely undocumented and impossible for the user to know.
2) We agree that « gnu gas » is an assembler whose duty is to assemble instructions. But « gas » will refuse to assemble those instructions. 
  Why is that? It is the responsibility of the programmer or the compiler to write the instructions that are present in this or another machine. 
  Why the assembler thinks it is necessary to forbid some instructions???
3) Obviously what is needed is a libc routine that will return the machine id. Then gcc and the user could use it to see which instructions are present, and that was the intent of my post.
4) Speaking of documentation. Since there wasn’t any documentation of the many small letters that are used by the GAS opcodes, I wrote one, and sent it to this group on July 27th. Since then there was ZERO answers to that message.  Why should I write documentation if none in this group cares?

OK, We agree that I should stop complaining, and writing documentation, and pointing out bugs.

Have a nice time


> Le 25 août 2023 à 17:32, Palmer Dabbelt <palmer@dabbelt.com> a écrit :
> 
> On Fri, 25 Aug 2023 07:12:39 PDT (-0700), jacob@jacob.remcomp.fr wrote:
>> OF COURSE « march » is mentioned. But -march=rv64gc_zbb is NOT.
>> 
>> Where please give me a link) that option is mentioned?
>> 
>> It is NOT mentioned in
>> 
>> https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html
> 
> The "-march" argument is documented int the "-march" section of the argument documentation, specifically:
> 
>   -march=ISA-string
> 	Generate code for given RISC-V ISA (e.g. ‘rv64im’). ISA strings 	must be lower-case. Examples include ‘rv64i’, ‘rv32g’, ‘rv32e’, 	and ‘rv32imaf’.
>              When -march= is not specified, use the setting from -mcpu.
>       	If both -march and -mcpu= are not specified, the default for 	this argument is system dependent, users who want a specific 	architecture extensions should specify one explicitly.
> 
> Pretty much every port has a "-march" argument to control the subtarget to generate code for.  It's true that the GCC docs for RISC-V's -march should be improved (there's even an unfinished patch out to do it, you're more than welcome to finish it), but the argument itself is definately documented.
> 
> Those are all GCC problems, though.  I suppose we could improve the binutils -march documentation as well, it'd essentially just be a duplicate of the GCC docs (aside from some quirks like Zihintpause).
> 
>> The idea that the compiler could figure out the processor it is running on it is completely far fetched isn’t it?
>> 
>> Jacob
>> 
>> 
>> 
>>> Le 25 août 2023 à 15:07, jacob navia <jacob@jacob.remcomp.fr> a écrit :
>>> OK, there is no bug, I didn’t expect anything else.
>>> SO:
>>> To use all the instruction of the processor he/she is running on, the user should:
>>> 1)Be aware that gcc doesn’t see crucial instructions of the processor by verifying its assembler output.
>>> 2) Be aware that there is an (undocumented) option -march… that will enable the assembler and the compiler to generate all the instructions of the current processor.
>>> Well, there is NO BUG!
>>> This is by design then.
>>> Thank you very much.
>>> Jacob
>>>> Le 25 août 2023 à 14:00, Jan Beulich <jbeulich@suse.com> a écrit :
>>>> On 25.08.2023 13:52, jacob navia wrote:
>>>>> The lack of the Ebb instructions is CRUCIAL for performance when accessing tables / arrays!
>>>>> This instructions allow to combine an addition and a shift by 1, 2 or 3, to access tables of shorts, ints or doubles.
>>>>> This speeds up the access to tables enormously and would allow gcc to generate much better code.
>>>> Since you're writing to binutils@, you may want to also mention what gas
>>>> bug you think you see. So far (also in the other mail) you've talked of
>>>> only gcc. If you meant to say that like in gcc you need to enable use of
>>>> the instructions in gas, then yes, that's the way the RISC-V assembler
>>>> works (like e.g. also the PPC one, but unlike e.g. the x86 one).
>>>> Jan

Re: P.S. Follow up to my last post

[Palmer Dabbelt]

On Fri, 25 Aug 2023 07:12:39 PDT (-0700), jacob@jacob.remcomp.fr wrote:
> OF COURSE « march » is mentioned. But -march=rv64gc_zbb is NOT.
>
> Where please give me a link) that option is mentioned?
>
> It is NOT mentioned in
>
> https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html

The "-march" argument is documented int the "-march" section of the 
argument documentation, specifically:

    -march=ISA-string
	Generate code for given RISC-V ISA (e.g. ‘rv64im’). ISA strings 
	must be lower-case. Examples include ‘rv64i’, ‘rv32g’, ‘rv32e’, 
	and ‘rv32imaf’.
        
        When -march= is not specified, use the setting from -mcpu.
        
	If both -march and -mcpu= are not specified, the default for 
	this argument is system dependent, users who want a specific 
	architecture extensions should specify one explicitly.

Pretty much every port has a "-march" argument to control the subtarget 
to generate code for.  It's true that the GCC docs for RISC-V's -march 
should be improved (there's even an unfinished patch out to do it, 
you're more than welcome to finish it), but the argument itself is 
definately documented.

Those are all GCC problems, though.  I suppose we could improve the 
binutils -march documentation as well, it'd essentially just be a 
duplicate of the GCC docs (aside from some quirks like Zihintpause).

> The idea that the compiler could figure out the processor it is running on it is completely far fetched isn’t it?
>
> Jacob
>
>
>
>> Le 25 août 2023 à 15:07, jacob navia <jacob@jacob.remcomp.fr> a écrit :
>> 
>> OK, there is no bug, I didn’t expect anything else.
>> 
>> SO:
>> 
>> To use all the instruction of the processor he/she is running on, the user should:
>> 
>> 1)Be aware that gcc doesn’t see crucial instructions of the processor by verifying its assembler output.
>> 
>> 2) Be aware that there is an (undocumented) option -march… that will enable the assembler and the compiler to generate all the instructions of the current processor.
>> 
>> Well, there is NO BUG!
>> 
>> This is by design then.
>> 
>> Thank you very much.
>> 
>> Jacob
>> 
>> 
>> 
>>> Le 25 août 2023 à 14:00, Jan Beulich <jbeulich@suse.com> a écrit :
>>> 
>>> On 25.08.2023 13:52, jacob navia wrote:
>>>> The lack of the Ebb instructions is CRUCIAL for performance when accessing tables / arrays!
>>>> This instructions allow to combine an addition and a shift by 1, 2 or 3, to access tables of shorts, ints or doubles.
>>>> This speeds up the access to tables enormously and would allow gcc to generate much better code.
>>> 
>>> Since you're writing to binutils@, you may want to also mention what gas
>>> bug you think you see. So far (also in the other mail) you've talked of
>>> only gcc. If you meant to say that like in gcc you need to enable use of
>>> the instructions in gas, then yes, that's the way the RISC-V assembler
>>> works (like e.g. also the PPC one, but unlike e.g. the x86 one).
>>> 
>>> Jan
>>