Re: Elimination of all floating point code in the tiny assembler

[Jan Beulich <jbeulich@suse.com>]

On 14.09.2023 09:49, jacob navia wrote:
>> Le 13 sept. 2023 à 13:18, Nick Clifton <nickc@redhat.com> a écrit :
>>> GAS has its own floating point code in very high precision. This code is quite cumbersome, and never used. All compilers emit floating point numbers as 32 or 64 bit integers, so, the directives for reading floating point numbers go unused.
>>
>> Except of course when assembling hand written assembler source code.
>> You can bet that there is code out there that relies upon this feature
>> of the assembler.
> 
> To make things clear: 
> 
> I haven’t taken away ANY user visible features. .double, etc, still continue to run as before. What changes is that instead of calling the floating point code in the assembler, I call the standard C library function « strtold ». That’s all. It continues a counter-trend: GNU software tends to reinvent the C library, and that is a bad idea. « strtold » knows well the machine it is running on..

But the machine the assembler is running on isn't necessarily relevant.

>> Another issue is that the code needs to work when running in a cross
>> assembly environment.  So for example it must work when running on a big
>> endian host but assembling for a little endian target, or when running
>> on a 32-bit host assembling for a 64-bit target.
> 
> Big endian hosts have disappeared long ago. SUN Microsystems died, Motorola died, I can’t name any big endian host, but maybe there are some left, I do not know.

Even the relatively new RISC-V still allows either endianness to be used,
if I'm not mistaken.

> Doing cross assembly in a 32 bit host for a 64 bit host… that looks weird but maybe possible, even if I would say that doing cross assembly in a 64 bit host for a 32 bit target would be more easy to find. Now: strtold doesn’t have anything to do with 32/64 bit stuff since the binary format of floating point numbers is specified by the ieee standard and should be the same in all little-endian machines.

Assuming all architectures you care about use IEEE representation only.
Think about x86'es 80-bit floating point data type, which - apart from
ia64 - probably isn't used much elsewhere. In x86 compilers you even
often can control via command line option what exactly long double is.
How is that going to work for your use of strtold() in all cases?

It also looks as if you don't really appreciate the value of cross tool
chains. That goes well beyond building a 32-bit assembler on a 64-bit
host (or vice versa) of otherwise the same architecture and OS (or, for
the latter, at least the same underlying ABI).

As to floating point "expressions" - I don't think gas supports these,
at least not the general case. It supports floating point values, but
that's (about?) it. And that has been necessary - beyond just .float
and .double - for something as commonly used as as glibc, until less
than a year ago. See
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=114e299ca66353fa7be1ee45bb4e1307d3de1fa2.

>> All of which is not to say "don't do this".  We absolutely would be
>> interested in any patches to improve/simplify the assembler.  Just please
>> do consider that the code needs to be portable, paranoid and pleasing.
> 
> Sure, I know that. But that has made the assembler frozen in a complexity that is absolutely incredible. Since the code should run in all kinds of machines that do not longer exist, developers can’t test!!!!!!!!!!!
> 
> I repeat: DEVELOPERS CAN’T TEST!!!!!!!!!

May I please ask that you stop shouting?

Jan