This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: forward references in equates


----Original Message----
>From: Jan Beulich
>Sent: 19 September 2005 16:37

>>>> "Dave Korn" <dave.korn@artimi.com> 19.09.05 17:21:04 >>>
>>  I was about to write this as well.  I think it would be bizarre if
>> changing the value of one went back and recalculated two and three. If I
>> wanted the value to change in that way, I'd do it by using a #define
>> macro and preprocessing my source, like this:
> 
> Unfortunately this won't always work - when you extensively use
> assembler macros, this generally conflicts with C-preprocessing here and
> there. Hence, as I view it, there should be a pure assembly solution to
> such problems. But maybe we really should use ia64's == operator for
> enforcing forward references...
> 
> Jan



  After your last post, I understand a bit better.  It still seems bizarre
to me, but hey, if that's the way some people like it, that's the way they
like it!

  OTOH, if gas is made to operate in the same way, I don't see how the new
behaviour could fail to break lots of existing code that uses redefined
symbols.

  So I'd just like to suggest that it should only and explicitly take place
for the new '==' operator, or only take place if there's a (new)
command-line switch specified, and that it should do so regardless of the
forwardness or backwardness of the references involved, and that snarfing
the text of the expression and re-evaluating it when any of the involved
symbols is redefined is the way to go.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]