Re: [patch] tic4x support in gas

["Svein E. Seldal" <Svein dot Seldal at solidas dot com>]

I have a strong feel that this discussion will end up in if we should
allow non-gas floats or not... Anyhow; According to the vendor's 
manuals, it expects floats to be in the following format:

   [+|-] [nnn] . [ nnn [E|e [+|-] nnn ] ]

Michael Hayes have used the vendor's syntax for immediate flonums in
opcodes generated from gcc deliberately to make the sourcecode 
compatible with the vendor's toolchain (and vice verse for the vendors 
code in gas).

gas is working properly as of this day for the cases where normal gas 
flonums are used (e.g. 0e3.14e0). Certain permutation of the "normal" 
float syntax above is allowed today. E.g.:

   1) "x.nnnn [e [+|-] nnn]"  works if  1 >= x <= 9.
   2) "0.nnnn" does not work
   3) "- nnnn . nnnn [e [+|-] nnn]" does not work

>>Index: expr.c
>>===================================================================
>>RCS file: /cvs/src/src/gas/expr.c,v
>>retrieving revision 1.45
>>diff -c -3 -p -r1.45 expr.c
>>*** expr.c	20 Sep 2002 00:58:39 -0000	1.45
>>--- expr.c	26 Sep 2002 11:30:18 -0000
>>*************** operand (expressionP)
>>*** 841,846 ****
>>--- 841,852 ----
>>        c = *input_line_pointer;
>>        switch (c)
>>  	{
>>+ #ifdef TC_TIC4X
>>+         case '.':  /* 0. */
>>+           floating_constant (expressionP);
>>+           break;
>>+ #endif
>>+
>>  	case 'o':
>>  	case 'O':
>>  	case 'q':
>
>
> You should be able to handle this a few lines above, changing
>
> 	  /* Check for a hex constant.  */
> 	  for (s = input_line_pointer; hex_p (*s); s++)
> 	    ;
> 	  if (*s == 'h' || *s == 'H')
> to
> 	  /* Check for a hex constant or floating point number.  */
> 	  for (s = input_line_pointer; hex_p (*s); s++)
> 	    ;
> 	  if (*s == 'h' || *s == 'H' || *input_line_pointer == '.')

Quite francly, I dont understand the difference. There is no difference 
as I can see to running the version that I suggest, and the one you 
suggest. They both do exactly the same... So if you could please 
enlighten me why the other is better :)

If you persist on having your version, I have no problem implementing it 
that way. It does not matter to me. BTW, should I use #ifdef TC_TIC4X on 
the code I add, or shouldn't I? Because the following construct is very 
bad IMHO!

#ifndef TC_TIC4X
 	  if (*s == 'h' || *s == 'H')
#else
 	  if (*s == 'h' || *s == 'H' || *input_line_pointer == '.')
#endif

This fixes the 2) case in the list above.


>>*************** operand (expressionP)
>>*** 1079,1084 ****
>>--- 1085,1100 ----
>>  	    else
>>  	      expressionP->X_add_number = ! expressionP->X_add_number;
>>  	  }
>>+ #ifdef TC_TIC4X
>>+         else if (expressionP->X_op == O_big && 
expressionP->X_add_number <= 0)
>>+         {
>>+             /* Negative flonum (eg, -1.000e0).  */
>>+             if (generic_floating_point_number.sign == '+')
>>+                 generic_floating_point_number.sign = '-';
>>+             else if (generic_floating_point_number.sign == 'P')
>>+                 generic_floating_point_number.sign = 'N';
>>+         }
>>+ #endif
>>  	else if (expressionP->X_op != O_illegal
>>  		 && expressionP->X_op != O_absent)
>>  	  {
>
>
> This is careless.  What about case '!' and case '~'?  Please fix
> your formatting too.

This fix is intended to fix the 3) case above. I see from testing that 
one of the code's side effects is that it also allows constructs like 
"-0e1.0", "~0e1.0" and "~1.0" that weren't allowed earlier. Are these 
constucts invalid? I would guess that the negative value of an flonum is 
ok, but what is the '~' of a flonum (now it behaves like a minus) :) I 
mean, we dont want such sideeffects, right?

Last, but least, would this code be allowed (please ignore the 
formatting)? Please explain why if not? I have a feeling, that it's the 
sign-fiddling that you dont like, right? How can I change the sign of a 
flonum operation like this? The X_op=O_uminus operation does not work 
the way I want it to...


#ifdef TC_TIC4X
        else if (expressionP->X_op == O_big && 
expressionP->X_add_number <= 0 && c == '-')
        {
            /* Negative flonum (eg, -1.000e0).  */
            if (generic_floating_point_number.sign == '+')
                  generic_floating_point_number.sign = '-';
                else if (generic_floating_point_number.sign == 'P')
                  generic_floating_point_number.sign = 'N';
            }
        }
#endif

I'll fix the code, after getting A's to the Q's in this mail. And I hope 
 I can get the answers to the questions I have, please.


Regards,
Svein