This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: H' hex constants
- From: Nick Clifton <nickc at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 08 Jul 2008 08:55:55 +0100
- Subject: Re: H' hex constants
- References: <200807072135.m67LZiUO024075@greed.delorie.com>
Hi DJ,
I've been asked to add H'00 syntax for hex constants to gas,
Is there a specification for this syntax ?
I've got added logic to brute-force all H'
into 0x but it doesn't handle things like FGH't' gracefully.
What about sequences like:
FGH'1234't
H'deadbeef't
'\H'
How are these supposed to be handled ?
One
problem is that there isn't a way to peek far enough ahead to see if
the character after the ' is a hex digit (you may not be able to unget
all those characters, and/or you may not be able to PUT() them all
into the output buffer).
Hmm - this suggests that changing do_scrub_chars(), although the most
straightforward approach, may not be the best way to solve the problem.
Another solution would be to create a gas specific string to integer
conversion function along the lines of strtoul() and use that
everywhere. A much more invasive approach I know, but it may be the
only real solution.
However, the current code will take something like H'1234 and replace
the '1 with 0x30 (48), resulting in a symbol called H49234.
You lost me there. Isn't the code supposed to change H'1234 into 0x1234
? And if you are replacing the two characters '1 with just one byte -
0x30 - shouldn't the resulting string be one byte shorter, ie: H0234 ?
Comments?
I think that enhancing do_scrub_chars is the best approach, but it
sounds like you will need to implement a two character peek ahead/ put-back.
Presumably this feature would be enabled on a per-target basis, so that
existing ports which do not need to support the syntax would not be
affected by the change ?
Cheers
Nick