This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: ebcdic support for binutils...


On Tue, Dec 11, 2001 at 10:03:01PM -0500, DJ Delorie wrote:
> 
> > hm. That's better?
> 
> Better than a compile error.  Not all compilers support #elif.

which ones? based on my experience with the os390 environment, I thought that 
os390 openedition was about as far as standard as you can get, and it supports 
#elif... Likewise, perl has elif in it, and I've never had complaints about
its portability. 

> > ( ps - what was the rationale for the hex replacement anyways?  I
> > thought the other file was much cleaner.)
> 
> The rationale was that you didn't need to initialize it at runtime if
> you could initialize it at compile time.  It's a performance boost.

yeah, but you only need to initialize it once - and I don't think that x < 1000
extra cycles is going to make that much difference in the runtime.

> I would approve a patch that defaulted to a zero-filled array,
> with explicit assignments for each digit, like this:
> 
> 	__hex_arr['4'] = 4;
> 	__hex_arr['A'] = 10;
> 	__hex_arr['B'] = 11;
> 
> etc.  You can't use for loops, though.
> 
> Unfortunately, You'd have to remove the ASCII table (replace it with
> an uninitialized array decl) also if you do this, else nobody will
> ever notice if you forget to call hex_init().

hmm. I'll keep it as is, but if someone wants to figure out the correct entries
to do this based on my patch, they are more than welcome...

Ed


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