Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Nov 2012 19:10:42 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Design idea for subarchs/abivariants

On Wed, Nov 28, 2012 at 11:38:02PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...ifal.cx> [2012-11-28 14:26:18 -0500]:
> > 2. Making bits/endian.h, bits/fenv.h, and any other bits headers that
> > need to vary per-subarch into generated headers. I think this could be
> > accomplished with a single rule for generating bits/%.h from
> > bits/%.h.sh the way alltypes.h is generated now. The full
> > $(ARCH)$(ENDIAN)$(SUBARCH) could be passed to the script as $1,
> > allowing simple shell logic to choose the right version to output.
> 
> i'm not sure about having many generated headers..
> 
> it could be a single generated bits/config.h with
> 
> #define __FPU 1
> #define __BYTEORDER 1234
> 
> and other bits/*.h could use these macros

Yes, I thought about this too and even started writing the email that
way before deleting what I wrote and rewriting it. I was trying to
avoid more nested and conditional inclusion, but I don't think it
would actually be too costly to do it the way you proposed.

> this way the generator is probably simpler,
> the drawback is that the cpp may need to do more
> work if bits/*.h have many conditional #if __FPU etc

I would at least use macro names that are less likely to conflict with
things a compiler might predefine.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.