Home Original page

Elimination of all floating point code in the tiny assembler

jacob navia jacob@jacob.remcomp.fr
Thu Sep 14 07:49:07 GMT 2023 
> Le 13 sept. 2023 à 13:18, Nick Clifton <nickc@redhat.com> a écrit :
> 
> Hi Jacob,
> 
>> 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..

> 
> A second point is that GAS actually has three different versions of the
> text-to-float conversion code: atof-generic.c, atof-ieee.c and atof-vax.c.

I know. I have replaced all three:

The first one, atof-ieee.c was replaced by strtold. The second has been dropped, since I do not support any floating point calculations in expressions any more. OK, you can try to support them forever, but I do not see why an assembler should support floating point calculations in assembler expressions!!!

Another problem with free software is that they are full of features nobody really uses. I just do not see in which context, making floating point calculations in assembler expressions is justified. Please enlighten me about that.

The third one (atof-vax.c) is obvious. The VAX stopped production in 2000. DEC corporation disappeared in 1998, bought by Compaq that stopped all VAXes in 2000. We are almost in 2024 now. It has been more than 25 years since DEC disappeared, and more than 20 years that the VAX disappeared. The grace period is over. 

> These are to support the requirements of different architectures.  Any
> replacement code would ideally remove all three of these implementations,
> although of course it would have to take care to not break anything.
> 

Look, free software is always trying to get funds. Normal. Declare all VAX support and floating point support OPTIONAL and PAYING consulting fees. :-)
You will see immediately that nobody uses those features.

> 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. 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.
> 
> 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!!!!!!!!!

And when you can’t test your changes you do not make any changes at all, and software gets ever more complex because the necessary cleanups are NEVER done!

That’s what I am trying to do now.

Have you ever run "gcc -analyze as.c" ???

You can’t… GCC can’t follow all the librairies (bfd, liberty, whatever) that are included in the code, can’t see the bugs in each of them!

But NOW it is possible. I have run « gcc -analyze asm.c » and after 15 minutes (in a riscv machine) I HAD ANSWERS pointing me to some bugs that I reported here. This is NEW and represents a great step in developing code in GAS.

I have created a framework where you CAN do changes in a relatively tiny piece of software and see all effects immediately. Just download the tiny assembler and you are all set. You have a small 35 000 lines asm.c and a 10 000 lines asm.h. Period. Nothing else. And compiles everywhere since it is standard C. Building it is as easy as typing "gcc -o asm asm.c -lz -lm «   And it has a 150 pages TECHNICAL DOCUMENTATION!!!!!, something that is completely missing for  the megabytes long source code of GAS.


Thanks for your input.

Jacob

P.S. The technical doc has 150 pages, as I said. It would be nice if somebody would read it...

> Cheers
>  Nick
More information about the Binutils mailing list