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 07:59:30PM -0800, esp5@rama.comp.pge.com wrote:
> 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.

I'm not sure when it was invented, but no, you can't count on #elif in
pre-C89 compilers.  I seem to remember reports that it isn't in the
HP/UX 9 bundled compiler, for instance.

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

The real win is being able to shove the table into the read-only data
segment.

> > 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().

I'd vote for removing hex_init and using big honking initialized
tables in carefully chosen order, the way safe-ctype does.

zw


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