[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how-to question: architecture dependent source

From: Stefano Lattarini
Subject: Re: how-to question: architecture dependent source
Date: Fri, 23 Mar 2012 10:58:33 +0100

On 03/23/2012 10:10 AM, Christopher Howard wrote:
> On 03/21/2012 03:39 PM, Christopher Howard wrote:
>> Hi. I'm still working on learning autotools (been reading through all
>> the manuals) so bear with me. There is something I've been trying to
>> figure out, and I would appreciate any guidance:
>> So, I write C code, and typically try to make it as portable as
>> possible. However, I also am somewhat enthusiastic about amd64 assembly
>> programming (with GAS syntax) - and so I like to optimize code for that
>> architecture.
>> What I want my configure script to do is check if I am compiling on the
>> amd64 architecture, and if so:
>> * define something appropriate in the config.h, which I can use to
>> conditionally leave out the more generic C functions from source files, and
>> * Put some extra (assembly) source files in a variable (e.g.
>> amd64sort.S, amd64insert.S, amd64filter.S...) so that they can be
>> appended as extra source in the Makefile. Presumably I'd have something
>> like this in
>> code:
>> --------
>> bin_PROGRAMS = myprogram
>> myprogram_SOURCES = ${ARCH_DEPS} myprogram.c
>> --------
>> I want to be able to have the assembly in separate source files, instead
>> of inline, for maintainability reasons.
> Er... hello? Anybody there? Hmm... must be my anti-magnetic personality.
Sorry, but it's not unusual for a message to go unanswered for few days
on this list.  Sometimes also for a week or more, seldom even forever.
We're all voluntaries here, so you get an answer only when we have time
to think and write it.

> Well, having despaired of getting outside help (if you can't get help at
> the autoconf mailing list, where else do you go?) I dove back into the
> problem, scouring the manuals as best I could. I was able to come up
> with this solution, which seems to work:
> * I had to add AC_PROG_AS to to get configure properly set
> up to use assembly.
You mean 'AM_PROG_AS', right?  If yes, that should be the correct way to

> * I added the following to to do the check, add to the
> config file, and prep things for automake:
> code:
> --------
> AC_CHECK_DECL([__amd64__],
> [AC_DEFINE([AMD64_OPT], 1, [Define to 1 to activate amd64 optimizations])
> echo engaging amd64 optimizations
> AM_CONDITIONAL([AMD64], [true])])
> --------
Not knowing anything of assembly myself (AMD64 nor generic), I cannot say
whether and how much this is correct.  But if it works correctly in your
use cases, chances are that it's good enough at least as a starting point;
you can refine it later if the needs arise.

> * I used this conditional in
> code:
> --------
> if AMD64
> myprogam_SOURCES = test.S myprogam.c
> else
> myprogam_SOURCES = myprogam.c
> endif
> --------
For what concerns automake, this is the way to go.  Such an idiom can work
more generally as well; in case you want to provide both a version optimized
for AMD64 and one optimized for SPARC of a given source file, as well as a
"fallback" C implementation, you could do something like this (untested):
  dnl: warning: totally fictitious checks
  AC_CHECK_DECL([__amd64__], [have_amd64=yes], [have_amd64=no])
  AC_CHECK_DECL([__sparc__], [have_sparc=yes], [have_sparc=no])
  AM_CONDITIONAL([AMD64], [test $have_amd64 = yes])
  AM_CONDITIONAL([SPARC], [test $have_sparc = yes])
  AM_CONDITIONAL([ASSEMBLY], [test $have_sparc = yes || test $have_amd64 = yes])
  myprogam_SOURCES = main.c generic.c
  if AMD64
  myprog_SOURCES += func-amd64.S
  if SPARC
  myprog_SOURCES += func-sparc.S
  else !ASSEMBLY
  myprog_SOURCES += func-generic.c
  endif ASSEMBLY

> Seems to work - not sure if it is the proper or sensible way to do it.
I'd says it is.

> Not sure how portable either: I think some systems use an __AMD64__
> declaration instead of __amd64__, but I'm not sure about that. I should
> perhaps be checking for either one.
I can't help you with this due to lack of knowledge on my part, sorry.

> I originally tried something more like what I mentioned in my first
> post, but automake died, complaining that "Configure substitutions are
> not allowed in _SOURCES variables".
This is expected, as currently Automake needs to know all the possible
contents of a _SOURCES variable at automake time (and AC_SUBSTs doesn't
allow that, while conditionals does).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]