By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,959 Members | 1,139 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,959 IT Pros & Developers. It's quick & easy.

how to make large macro paste the code as it is

P: n/a
how to make large macro paste the code as it is

Problem Explanation '--
For example in the program below

/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;

int main (){
DECL_VARS();
}

/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}

PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

SOLUTION : ??

--
vpn
Nov 11 '08 #1
Share this Question
Share on Google+
36 Replies


P: n/a
sh******@gmail.com writes:
how to make large macro paste the code as it is

Problem Explanation '--
For example in the program below

/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;

int main (){
DECL_VARS();
}

/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}

PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

SOLUTION : ??
Use a single array. This is what they are for!

--
Ben.
Nov 11 '08 #2

P: n/a
On Nov 11, 7:59*pm, sh.vi...@gmail.com wrote:
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
What makes you think that that will be a problem? C ignores redundant
white space. The compiler sees statements, not lines. I'm not aware of
any "line length maximum".
Nov 11 '08 #3

P: n/a
On 11 Nov, 12:59, sh.vi...@gmail.com wrote:
how to make large macro paste the code as it is

Problem Explanation '--
For example in the program below

/* a.c *- starts here */
#define DECL_VARS() \
* * * * unsigned int a0;\
* * * * unsigned int a1;\
* * * * unsigned int a2;\
* * * * unsigned int a3;

int main (){
* * * * DECL_VARS();

}

/* a.c -- ends here */

After macro processing, program becomes as follows.
int main (){
* unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;

}

PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

SOLUTION : ??
what is the actual syntax error?

could you use more than one macro?

do you *really* need to declare >350 identifiers?

could you write a program to generate the identifiers instead of a
macro?

--
Nick Keighey

I'd rather write programs to write programs than write programs

(define (decl-vars count)
(if (not (= count 0))
(begin
(decl-vars (- count 1))
(display "\tunsigned int a")
(display (- count 1))
(display ";")
(newline))))
Nov 11 '08 #4

P: n/a
On Nov 11, 6:16 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
sh.vi...@gmail.com writes:
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??

Use a single array. This is what they are for!

--
Ben.
yes it can be a solution but will not that effect performance? My
concern is if i need only a[34] then will only a[34] will be brought
in cache or locality of reference is applied and some major chunk is
taken. Moreover indexing will take place which might effect the
performance.

Do u agree? please give your feedback.

--
v[i]p[i]n
Nov 11 '08 #5

P: n/a
On Nov 11, 6:21 pm, Tomás Ó hÉilidhe <t...@lavabit.comwrote:
On Nov 11, 7:59 pm, sh.vi...@gmail.com wrote:
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

What makes you think that that will be a problem? C ignores redundant
white space. The compiler sees statements, not lines. I'm not aware of
any "line length maximum".
Ok, yes may be it is a line length maximum problem. Sorry for
incorrect assumption but then what can be the solution?

--
vipin
Nov 11 '08 #6

P: n/a
On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 11 Nov, 12:59, sh.vi...@gmail.com wrote:
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??

what is the actual syntax error?

could you use more than one macro?

do you *really* need to declare >350 identifiers?

could you write a program to generate the identifiers instead of a
macro?

--
Nick Keighey

I'd rather write programs to write programs than write programs

(define (decl-vars count)
(if (not (= count 0))
(begin
(decl-vars (- count 1))
(display "\tunsigned int a")
(display (- count 1))
(display ";")
(newline))))

actual syntax error is "parse error 1"
yes, unfortunately i need them. imagine a situation where there is a
digital circuit of 25000 logic GATES(AND/OR/XOR)
and i have to generate equivalent C code for the same. since i have
to generate the c code i don;t know variable names also in advance

Also breaking macros is not a solution i think because following
program also gives same output after preprocessing.
plz correct if i m missing here something


#define DECL_VARS1() \
unsigned int x;\
unsigned int y;

#define DECL_VARS2() \
unsigned int z;\
unsigned int a;

#define DECL_VARS() \
DECL_VARS1() \
DECL_VARS2()

int main (){
DECL_VARS();
}
Nov 11 '08 #7

P: n/a
sh******@gmail.com writes:
On Nov 11, 6:16 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>sh.vi...@gmail.com writes:
<snip>
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??

Use a single array. This is what they are for!

--
Ben.
Best not quote sig blocks.
yes it can be a solution but will not that effect performance?
Maybe, maybe not. The only way it try it and see. I'd always choose
the clear version first and optimise if there seems to be a
performance problem.
My
concern is if i need only a[34] then will only a[34] will be brought
in cache or locality of reference is applied and some major chunk is
taken. Moreover indexing will take place which might effect the
performance.

Do u agree? please give your feedback.
On many systems you will get exactly the same code to access a[5] as
you do for a5 (if both are auto). I can't see a reason to suspect a
cache problem but, again, I would worry about that later only if you
need to.

--
Ben.
Nov 11 '08 #8

P: n/a
sh******@gmail.com writes:
On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
<snip>
>do you *really* need to declare >350 identifiers?
<snip>
yes, unfortunately i need them.
No, you need an array. The variables are a kludge.

http://en.wikipedia.org/wiki/Kludge

--
Ben.
Nov 11 '08 #9

P: n/a

<sh******@gmail.comwrote in message
news:ef**********************************@a17g2000 prm.googlegroups.com...
On Nov 11, 6:16 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>sh.vi...@gmail.com writes:
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??

Use a single array. This is what they are for!
yes it can be a solution but will not that effect performance? My
concern is if i need only a[34] then will only a[34] will be brought
in cache or locality of reference is applied and some major chunk is
taken. Moreover indexing will take place which might effect the
performance.
Indexing should make no difference for a constant index. The code for
accessing a34 or a[34] should be the same.

The cache effects also have little to do with this; all the hardware knows
is that you are accessing a 2,4 or 8 byte value at some address.

--
Bartc

Nov 11 '08 #10

P: n/a
Tomás Ó hÉilidhe wrote:
On Nov 11, 7:59 pm, sh.vi...@gmail.com wrote:
>PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

What makes you think that that will be a problem? C ignores redundant
white space. The compiler sees statements, not lines. I'm not aware of
any "line length maximum".
This involves the notorious "one program" requirement.

5.2.4p1: "... 4095 characters in a logical source line ...".

That limit doesn't literally mean what it seems to mean; the only
requirement that limit actually applies to is that every compiler must
have at least one program that it translates and executes correctly.
This one program must, among other things, have at least one logical
source line with at least 4095 characters in it.

A program meeting all of the requirements listed in 5.2.4 would have to
be very long, but it can be chosen by the vendor to avoid any weaknesses
in the implementation. Such a could be functionally equivalent to

int main(void) { return 0;}

As a result, this requirement is almost meaningless.

Nonetheless, the intent seems to have been that developers should worry
about exceeding any of the limits listed in section 5.2.4p1. As a
practical matter, I think that's the way the passage should be treated,
though I strongly favor a re-write to make it impose a more meaningful
requirement.
Nov 11 '08 #11

P: n/a
sh******@gmail.com wrote:
On Nov 11, 6:16 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>sh.vi...@gmail.com writes:
>>how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
....
>Use a single array. This is what they are for!
....
yes it can be a solution but will not that effect performance? My
concern is if i need only a[34] then will only a[34] will be brought
in cache or locality of reference is applied and some major chunk is
taken.
Accessing a[34] does not require access to any part of memory other than
that used to store the 35th element of 'a', so there should be no effect
on caching.
... Moreover indexing will take place which might effect the
performance.
No, that will not be an issue. The compiler knows just as much about the
location of a[34] as it does about a34; it should generate equally
efficient code to access either piece of memory.
Nov 11 '08 #12

P: n/a
Tomás Ó hÉilidhe <to*@lavabit.comwrote:
On Nov 11, 7:59*pm, sh.vi...@gmail.com wrote:
>PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

What makes you think that that will be a problem? C ignores redundant
white space. The compiler sees statements, not lines. I'm not aware of
any "line length maximum".

Compiler generally cannot handle arbitrarily long lines, so there is indeed
a 'line length maximum', the exact value of which varies between compilers.

The C99 standard says that compilers must be able to handle logical line lengths
of up to 4095 characters, so lines longer than that are not portable even if many
compilers can handle longer lines.

(This is an improvment over C89 which, IIRC, only required compilers to handle
lines of up to 511 characters.)

--
<Insert your favourite quote here.>
Erik Trulsson
er******@student.uu.se
Nov 11 '08 #13

P: n/a

<sh******@gmail.comwrote in message
news:d6**********************************@w1g2000p rk.googlegroups.com...
how to make large macro paste the code as it is

Problem Explanation '--
For example in the program below

/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;

int main (){
DECL_VARS();
}

/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}

PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.

SOLUTION : ??
If you in fact needed such a large number of declarations in a
parameter-less macro (for the purposes of repeating them presumably), then I
think you should look at include files.

Then you can put each declaration on it's own line. For example, put the
declarations into decl_vars.h (without the \ on each line) then use:

#include "decl_vars.h"

--
Bartc

Nov 11 '08 #14

P: n/a
On 11 Nov, 14:17, sh.vi...@gmail.com wrote:
On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 11 Nov, 12:59, sh.vi...@gmail.com wrote:
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c *- starts here */
#define DECL_VARS() \
* * * * unsigned int a0;\
* * * * unsigned int a1;\
* * * * unsigned int a2;\
* * * * unsigned int a3;
int main (){
* * * * DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
* unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??
what is the actual syntax error?
could you use more than one macro?
do you *really* need to declare >350 identifiers?
could you write a program to generate the identifiers instead of a
macro?
--
Nick Keighey
you shouldn't normally quote sigs (the bit after "-- ")
actual syntax error is "parse error 1"
yuk. Take out a contract on the compiler writer! :-)

yes, unfortunately i need them. imagine a situation where there is a
digital circuit of 25000 logic GATES(AND/OR/XOR)
*and i have to generate equivalent C code for the same. since i have
to generate the c code i don;t know variable names also in advance
you must know the variable names at *some* point...

Also breaking macros is not a solution i think because following
program also gives same output after preprocessing.
so it isn't the fact that there are too many on one line.
Maybe too many variables. 250000 variables is quite a lot...

plz correct if i m missing here something

#define DECL_VARS1() \
* * * * unsigned int x;\
* * * * unsigned int y;

#define DECL_VARS2() \
* * * * unsigned int z;\
* * * * unsigned int a;

#define DECL_VARS() \
* * * * DECL_VARS1() \
* * * * DECL_VARS2()

int main (){
* * * * DECL_VARS();

}
well you have glued them back together again.
What does this do

int main(void)
{
DECL_VARS1();
DECL_VARS2();
return 0;
}

Does your compiler really accept an empty macro
parameter list?
--
Nick Keighley
Nov 11 '08 #15

P: n/a
Ben Bacarisse <be********@bsb.me.ukwrites:
sh******@gmail.com writes:
>On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
<snip>
>>do you *really* need to declare >350 identifiers?
<snip>
>yes, unfortunately i need them.

No, you need an array. The variables are a kludge.

http://en.wikipedia.org/wiki/Kludge

So he needs things to be slow? And there I was thinking that one of
the reasons he might use C would be for its speed!
phil@nonospaz:tmp$ time ./crap_vars

real 0m1.807s
user 0m1.744s
sys 0m0.000s

phil@nonospaz:tmp$ time ./crap_array

real 0m2.507s
user 0m2.320s
sys 0m0.000s
where crap_* was compiled from something beginning:
#define ARRAY
#if defined(ARRAY)
# define VAR(number) var[number]
#else
# define VAR(number) var##number
#endif

int main(int argc, char**argv)
{
#if defined(ARRAY)
double var[100];
#else
double
var0=1., var1=1., var2=1., var3=1., var4=1., var5=1., var6=1., var7=1., var8=1., var9=1.,
// ... 90 more
;
#endif

// ... do stuff with various subsets of the VAR()s.

}
Phil

--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Nov 11 '08 #16

P: n/a
sh******@gmail.com writes:
On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>On 11 Nov, 12:59, sh.vi...@gmail.com wrote:
do you *really* need to declare >350 identifiers?

yes, unfortunately i need them. imagine a situation where there is a
digital circuit of 25000 logic GATES(AND/OR/XOR)
and i have to generate equivalent C code for the same. since i have
to generate the c code i don;t know variable names also in advance
Why do you need to declare them before their first use?
(There are several good answers to that question.)

Why do you need to do this by generating C pre-processor code
rather than C code?

Can your C pre-processor handle the long lines?
If so, can't you pre-process the C, then apply a simple
sed script, and then compile the output of that?

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Nov 11 '08 #17

P: n/a
On Nov 11, 8:29*pm, "Bartc" <b...@freeuk.comwrote:
<sh.vi...@gmail.comwrote in message

news:d6**********************************@w1g2000p rk.googlegroups.com...
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c *- starts here */
#define DECL_VARS() \
*unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
*unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??

If you in fact needed such a large number of declarations in a
parameter-less macro (for the purposes of repeating them presumably), then I
think you should look at include files.

Then you can put each declaration on it's own line. For example, put the
declarations into decl_vars.h (without the \ on each line) then use:

#include "decl_vars.h"

--
Bartc
yes actually that solution I had in my mind but actually the issue is
i have to write 1000s of such functions and every function has its own
declarations. so in this case i will have to write 1000s of files,
each for each set of declaration i.e. each function. I wanted to put
these declarations(+definition) at one place earlier and let all the
functions share these common variable names. But that gives
performance degradation over local variable usage. All i amm trying to
avoid is save "1" traversal of logic. Probably I must sacrifice that
to get the readable and even more importantly compilable code.

--
vIpIn
Nov 11 '08 #18

P: n/a
>
Why do you need to declare them before their first use?
(There are several good answers to that question.)
I want to make them local to function for better results. will it
compile otherwise ?
Why do you need to do this by generating C pre-processor code
rather than C code?
b'coz i first know the code that uses the variable and then list of
all the variables. since i am generating the code, that means our tool
writing the C code in file, first the code is written that uses the
varable and then i know at the end of function what my list of
variables conclude. So i want to insert a macro immediately after the
opening brace that will expand to variable declarations later.

May be i should use FILE handling calls like lseek and other to save
the position where i must add declarations after finishing writing the
function

--
vipin

Can your C pre-processor handle the long lines?
If so, can't you pre-process the C, then apply a simple
sed script, and then compile the output of that?

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Nov 11 '08 #19

P: n/a
Phil Carmody <th*****************@yahoo.co.ukwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>sh******@gmail.com writes:
>>On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
<snip>
>>>do you *really* need to declare >350 identifiers?
<snip>
>>yes, unfortunately i need them.

No, you need an array. The variables are a kludge.

http://en.wikipedia.org/wiki/Kludge


So he needs things to be slow?
No, but am I suggesting he get his priorities right. What evidence is
there that an array is too slow for the intended use? If there is
some, then sure lets help fix that, but until then I favour the
obvious solution..

<snip times>
#define ARRAY
#if defined(ARRAY)
# define VAR(number) var[number]
#else
# define VAR(number) var##number
#endif

int main(int argc, char**argv)
{
#if defined(ARRAY)
double var[100];
#else
double
var0=1., var1=1., var2=1., var3=1., var4=1., var5=1., var6=1., var7=1., var8=1., var9=1.,
// ... 90 more
;
#endif

// ... do stuff with various subsets of the VAR()s.

}
Can you post the actual code?

Originally I looked at the assembler generated for array vs variable
access and saw no differences which is why I suggested there might be
little effect (on at least some systems). You may have found examples
where there is a difference but when I tried a few things, I get the
same times. (and essentially the same code, too).

--
Ben.
Nov 11 '08 #20

P: n/a
Ben Bacarisse <be********@bsb.me.ukwrites:
Originally I looked at the assembler generated for array vs variable
access and saw no differences which is why I suggested there might be
little effect (on at least some systems). You may have found examples
where there is a difference but when I tried a few things, I get the
same times. (and essentially the same code, too).
I wouldn't be surprised if some optimizations don't work as well with
arrays as with scalar (constant propagation would be the first one I'd try
if I wanted to search differences).

Yours,

--
Jean-Marc
Nov 11 '08 #21

P: n/a
On Nov 11, 11:26*am, Phil Carmody <th*****************@yahoo.co.uk>
wrote:
Ben Bacarisse <be********@bsb.me.ukwrites:
sh******@gmail.com writes:
On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
<snip>
>do you *really* need to declare >350 identifiers?
<snip>
yes, unfortunately i need them.
No, you need an array. *The variables are a kludge.
http://en.wikipedia.org/wiki/Kludge

So he needs things to be slow? And there I was thinking that one of
the reasons he might use C would be for its speed!
Maybe, but if he needs to do all these workarounds because C arrays
are too slow (which I doubt), then it means it's not fast enough.
Abusing the preprocessor like this is definitely not the way to code
C.

Next stop: assembly language.

Sebastian

Nov 11 '08 #22

P: n/a
Ben Bacarisse <be********@bsb.me.ukwrites:
Phil Carmody <th*****************@yahoo.co.ukwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>sh******@gmail.com writes:

On Nov 11, 6:39 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
<snip>
do you *really* need to declare >350 identifiers?
>
<snip>
yes, unfortunately i need them.

No, you need an array. The variables are a kludge.

http://en.wikipedia.org/wiki/Kludge


So he needs things to be slow?

No, but am I suggesting he get his priorities right. What evidence is
there that an array is too slow for the intended use? If there is
some, then sure lets help fix that, but until then I favour the
obvious solution..

<snip times>
>#define ARRAY
#if defined(ARRAY)
# define VAR(number) var[number]
#else
# define VAR(number) var##number
#endif

int main(int argc, char**argv)
{
#if defined(ARRAY)
double var[100];
#else
double
var0=1., var1=1., var2=1., var3=1., var4=1., var5=1., var6=1., var7=1., var8=1., var9=1.,
// ... 90 more
;
#endif

// ... do stuff with various subsets of the VAR()s.

}

Can you post the actual code?
It was semi-random typing. I wanted to isolate a small number
of the variables, exercise them heavily in an inner loop, and
then switch to another not-quite disjoint subset of the variables.
The intention was simply to confuse the register allocator. The
very first thing I threw together gave a 4:3 ratio in favour of
the variables rather than the array. Of course, this is a pure
QoI issue - the compiler was simply too easily confused in this
particular instance. The missing parts were:

int i,j;
const double half=0.5;
#define INNER 100000
#define OUTER 1000
for(i=0; i<OUTER; ++i)
{
for(j=0; j<INNER; ++j)
{
VAR(13)=(VAR(29)+VAR(72)*VAR(91))*half;
VAR(91)=VAR(13)-VAR(27)*VAR(29)*half;
VAR(27)=VAR(72)*VAR(27)+VAR(29);
}
for(j=0; j<INNER; ++j)
{
VAR(43)=(VAR(29)+VAR(71)*VAR(91))*half;
VAR(91)=VAR(43)-VAR(27)*VAR(29)*half;
VAR(27)=VAR(71)*VAR(27)+VAR(29);
}
for(j=0; j<INNER; ++j)
{
VAR(13)=(VAR(43)+VAR(72)*VAR(91))*half;
VAR(91)=VAR(13)-VAR(80)*VAR(43)*half;
VAR(80)=VAR(72)*VAR(80)+VAR(43);
}
for(j=0; j<INNER; ++j)
{
VAR(80)=(VAR(29)+VAR(43)*VAR(91))*half;
VAR(7)=VAR(13)-VAR(80)*VAR(29)*half;
VAR(27)=VAR(72)*VAR(7)+VAR(29);
}
}
return (int)(VAR(27)+VAR(80)+VAR(91));
}
Originally I looked at the assembler generated for array vs variable
access and saw no differences which is why I suggested there might be
little effect (on at least some systems). You may have found examples
where there is a difference but when I tried a few things, I get the
same times. (and essentially the same code, too).
Unfortunately, I have no explanation for why the compiler got
confused, but I'm glad that the first thing I tried did confuse
it. (This was gcc-4.3 on x86) I've seen Apple's Xcode compiler
(a gcc variant, I think) get very confused by register allocations
for registers when it was a tight fit in the past too. (I've
seen it only use 30 registers, and spill other values to RAM!)
Compilers aren't perfect.

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Nov 11 '08 #23

P: n/a
Jean-Marc Bourguet <jm@bourguet.orgwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Originally I looked at the assembler generated for array vs variable
access and saw no differences which is why I suggested there might be
little effect (on at least some systems). You may have found examples
where there is a difference but when I tried a few things, I get the
same times. (and essentially the same code, too).

I wouldn't be surprised if some optimizations don't work as well with
arrays as with scalar (constant propagation would be the first one I'd try
if I wanted to search differences).
Even if the index is a compile-time constant (as it will be in this
case)?

You may well be right, but some very simple tests with gcc shows it
doing constant propagation with a[0] as easily as with a0.

--
Ben.
Nov 11 '08 #24

P: n/a
Phil Carmody <th*****************@yahoo.co.ukwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
<snip>
>Can you post the actual code?

It was semi-random typing. I wanted to isolate a small number
of the variables, exercise them heavily in an inner loop, and
then switch to another not-quite disjoint subset of the variables.
The intention was simply to confuse the register allocator. The
very first thing I threw together gave a 4:3 ratio in favour of
the variables rather than the array. Of course, this is a pure
QoI issue - the compiler was simply too easily confused in this
particular instance. The missing parts were:
I think there must have been an initialisation of the array. Without
it (I did not spot that first off) gcc was way faster with the array
version than the 100 variable version! It turned out the optimiser
was taking advantage of UB to do some very aggressive code changes.
With the array initialised to ones, I also see an advantage to the
variable code.

I *still* would not use such a technique unless I really knew it would
matter. These tests show that any speed gain depends very much on
exactly what the real code is, and we have not seen that yet.

I certainly concede that there may be something to be gained by the
hassle, but I think using hundreds of variables rather than an
single array is a classic case of premature optimisation.

--
Ben.
Nov 12 '08 #25

P: n/a
Ben Bacarisse <be********@bsb.me.ukwrites:
Phil Carmody <th*****************@yahoo.co.ukwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
<snip>
>>Can you post the actual code?

It was semi-random typing. I wanted to isolate a small number
of the variables, exercise them heavily in an inner loop, and
then switch to another not-quite disjoint subset of the variables.
The intention was simply to confuse the register allocator. The
very first thing I threw together gave a 4:3 ratio in favour of
the variables rather than the array. Of course, this is a pure
QoI issue - the compiler was simply too easily confused in this
particular instance. The missing parts were:
....
I certainly concede that there may be something to be gained by the
hassle, but I think using hundreds of variables rather than an
single array is a classic case of premature optimisation.
If you look at the latest optimiser rejig in GCC, it's effectively
the creation of huge numbers of auto variables. I can't remember
what they call the technique, but I can't say I found it very
innovative. It's very much like the style of C that Dan Bernstein,
for example, has been exploiting for speed since 1320, simply relying
on basic register coulouring. Yes, it's not necessarily clean and
neat, but sometimes it gets the job done. I'd certainly rather
introduce a new variable than re-use an old one that I was no longer
using 99% of the time, when speed's an issue.

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
Nov 12 '08 #26

P: n/a
sh******@gmail.com wrote:
#define DECL_VARS1() \
unsigned int x;\
unsigned int y;

#define DECL_VARS2() \
unsigned int z;\
unsigned int a;

#define DECL_VARS() \
DECL_VARS1() \
DECL_VARS2()

int main (){
DECL_VARS();
}
Be aware that there is an extra semicolon after the last declaration. That
is not a problem if you follow with executable code or you are using C99.
It could be a problem with C89. Also, although it is supported by most C89
compilers, I recall that a function-like macro definition without
parameters is not defined by the C89 standard (I have used them with no
problems).

I suggest you look at the preprocessor output to see what is happening.

--
Thad
Nov 12 '08 #27

P: n/a
On Nov 11, 1:08*pm, sh.vi...@gmail.com wrote:
On Nov 11, 8:29*pm, "Bartc" <b...@freeuk.comwrote:
<sh.vi...@gmail.comwrote in message
news:d6**********************************@w1g2000p rk.googlegroups.com...
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c *- starts here */
#define DECL_VARS() \
*unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
*unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??
If you in fact needed such a large number of declarations in a
parameter-less macro (for the purposes of repeating them presumably), then I
think you should look at include files.
Then you can put each declaration on it's own line. For example, put the
declarations into decl_vars.h (without the \ on each line) then use:
#include "decl_vars.h"
--
Bartc

yes actually that solution I had in my mind but actually the issue is
i have to write 1000s of such functions and every function has its own
declarations. so in this case i will have to write 1000s of files,
each for each set of declaration i.e. each function. I wanted to put
these declarations(+definition) at one place earlier and let all the
functions share these common variable names. But that gives
performance degradation over local variable usage. All i amm trying to
avoid is save "1" traversal of logic. Probably I must sacrifice that
to get the readable and even more importantly compilable code.

--
vIpIn
Why 1000s of files? It isn't common usage (at least that I've seen),
but if you put #include inside the functions it seems like it does
what you want?

temp(798)$ cat decls.h
int a0;
int a1;
temp(799)$ cat foo.c
#include <stdio.h>

static void foo()
{
#include "decls.h"
a0 = 1;
a1 = 2;
printf("a0=%d,a1=%d\n", a0, a1);
}

static void bar()
{
#include "decls.h"
a0 = 3;
a1 = 4;
printf("a0=%d,a1=%d\n", a0, a1);
}

int main(void)
{
foo();
bar();

return 0;
}
temp(800)$ gcc -Wall -o foo foo.c
temp(801)$ foo
a0=1,a1=2
a0=3,a1=4

-David
Nov 12 '08 #28

P: n/a
sh******@gmail.com writes:
how to make large macro paste the code as it is

Problem Explanation '--
For example in the program below

/* a.c - starts here */
#define DECL_VARS() \
As a stylistic point, I would define DECL_VARS, not DECL_VARS(). This
macro doesn't behave like a function, so there's no reason to mimic
function syntax.
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;

int main (){
DECL_VARS();
Likewise, I'd just use

DECL_VARS

when calling it. As someone else pointed out, the extra semicolon
becomes an empty statement, which could cause a problem if you are using
C89 which does not allow statements to be interspersed with
declarations.
}

/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}

PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
Have you considered getting a less crummy compiler? For example, GCC
has no problem with the code you give, even when I increase the number
of variables to 500000. Others have mentioned that the C standard does
not *require* compilers to accept such long lines, but IMHO any decent
compiler *should* not impose any fixed limit at all on line length.
Nov 12 '08 #29

P: n/a

"Nate Eldredge" <na**@vulcan.lanwrote in message
news:86************@vulcan.lan...
sh******@gmail.com writes:
>how to make large macro paste the code as it is

Problem Explanation '--
For example in the program below

/* a.c - starts here */
#define DECL_VARS() \

As a stylistic point, I would define DECL_VARS, not DECL_VARS(). This
macro doesn't behave like a function, so there's no reason to mimic
function syntax.
> unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;

int main (){
DECL_VARS();

Likewise, I'd just use

DECL_VARS

when calling it. As someone else pointed out, the extra semicolon
becomes an empty statement, which could cause a problem if you are using
C89 which does not allow statements to be interspersed with
declarations.
[...]

If a function-like macro is required, it could be defined as:

__________________________________________________ ________________
#define DECL_VARS_IMPL(type, prefix) \
type prefix##_##0, prefix##_##1, prefix##_##2, prefix##_##3

#define DECL_VARS(type, prefix) \
DECL_VARS_IMPL(type, prefix)
int main(void) {
{
DECL_VARS(unsigned int, unsigned_int);
DECL_VARS(unsigned long int, unsigned_long_int);
DECL_VARS(short int, short_int);
}

{
#define INVOKE_IMPL(macro_function, p) macro_function p

#define INVOKE(macro_function, p) \
INVOKE_IMPL(macro_function, p)

INVOKE(DECL_VARS, (unsigned int, unsigned_int));
INVOKE(DECL_VARS, (unsigned long int, unsigned_long_int));
INVOKE(DECL_VARS, (short int, short_int));
}

return 0;
}
__________________________________________________ ________________


no problem with C89. Also, one possible "advantage" to making `DECL_VARS' a
function-macro; refer to simple `INVOKE' macro. You can use `DECL_VARS' as a
"macro function pointer", and pass it around, macros, and only invoke it, or
expose it to expansion, once the final `()' is appended. Here is example of
function-macros that can generate a static tables of POSIX synchronization
objects:
http://webpages.charter.net/appcore/...efcount-c.html
Notice the `PLACE' macro and the following statements:
static pthread_mutex_t g_locktbl[LOCKTBL_DEPTH()] = {
PLACE(LOCKTBL_INIT, LOCKTBL_DEPTH())
};

static pthread_rwlock_t g_rwlocktbl[LOCKTBL_DEPTH()] = {
PLACE(LOCKTBL_RWINIT, LOCKTBL_DEPTH())
};

AFAICT, this simple pre-processor technique can be fairly useful...

Nov 12 '08 #30

P: n/a
On Nov 12, 6:52 am, David Resnick <lndresn...@gmail.comwrote:
On Nov 11, 1:08 pm, sh.vi...@gmail.com wrote:
On Nov 11, 8:29 pm, "Bartc" <b...@freeuk.comwrote:
<sh.vi...@gmail.comwrote in message
>news:d6**********************************@w1g2000 prk.googlegroups.com...
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c - starts here */
#define DECL_VARS() \
unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??
If you in fact needed such a large number of declarations in a
parameter-less macro (for the purposes of repeating them presumably), then I
think you should look at include files.
Then you can put each declaration on it's own line. For example, put the
declarations into decl_vars.h (without the \ on each line) then use:
#include "decl_vars.h"
--
Bartc
yes actually that solution I had in my mind but actually the issue is
i have to write 1000s of such functions and every function has its own
declarations. so in this case i will have to write 1000s of files,
each for each set of declaration i.e. each function. I wanted to put
these declarations(+definition) at one place earlier and let all the
functions share these common variable names. But that gives
performance degradation over local variable usage. All i amm trying to
avoid is save "1" traversal of logic. Probably I must sacrifice that
to get the readable and even more importantly compilable code.
--
vIpIn

Why 1000s of files? It isn't common usage (at least that I've seen),
but if you put #include inside the functions it seems like it does
what you want?

temp(798)$ cat decls.h
int a0;
int a1;
temp(799)$ cat foo.c
#include <stdio.h>

static void foo()
{
#include "decls.h"
a0 = 1;
a1 = 2;
printf("a0=%d,a1=%d\n", a0, a1);

}

static void bar()
{
#include "decls.h"
a0 = 3;
a1 = 4;
printf("a0=%d,a1=%d\n", a0, a1);

}

int main(void)
{
foo();
bar();

return 0;}

temp(800)$ gcc -Wall -o foo foo.c
temp(801)$ foo
a0=1,a1=2
a0=3,a1=4

-David
yes but then there compiler will have to do unused variable
optimization and so many warnings in the code. Though I am sure, some
of you will say that first I write such a bad code and then even worry
about the warnings. But the fact is this code ie being written by tool
(i.e. computer) not by me. I certainly write better than them. :-)

--
vipin
Nov 12 '08 #31

P: n/a
On Nov 12, 8:36*am, sh.vi...@gmail.com wrote:
On Nov 12, 6:52 am, David Resnick <lndresn...@gmail.comwrote:
On Nov 11, 1:08 pm, sh.vi...@gmail.com wrote:
On Nov 11, 8:29 pm, "Bartc" <b...@freeuk.comwrote:
<sh.vi...@gmail.comwrote in message
news:d6**********************************@w1g2000p rk.googlegroups.com...
how to make large macro paste the code as it is
Problem Explanation '--
For example in the program below
/* a.c *- starts here */
#define DECL_VARS() \
*unsigned int a0;\
unsigned int a1;\
unsigned int a2;\
unsigned int a3;
int main (){
DECL_VARS();
}
/* a.c -- ends here */
After macro processing, program becomes as follows.
int main (){
*unsigned int a0; unsigned int a1; unsigned int a2; unsigned int a3;
}
PROBLEM: is when number of such variable declarations in a single
macro is too large, say a0 - a350, there will be parse error because
too many variable declarations in same line.
SOLUTION : ??
If you in fact needed such a large number of declarations in a
parameter-less macro (for the purposes of repeating them presumably), then I
think you should look at include files.
Then you can put each declaration on it's own line. For example, put the
declarations into decl_vars.h (without the \ on each line) then use:
#include "decl_vars.h"
--
Bartc
yes actually that solution I had in my mind but actually the issue is
i have to write 1000s of such functions and every function has its own
declarations. so in this case i will have to write 1000s of files,
each for each set of declaration i.e. each function. I wanted to put
these declarations(+definition) at one place earlier and let all the
functions share these common variable names. But that gives
performance degradation over local variable usage. All i amm trying to
avoid is save "1" traversal of logic. Probably I must sacrifice that
to get the readable and even more importantly compilable code.
--
vIpIn
Why 1000s of files? *It isn't common usage (at least that I've seen),
but if you put #include inside the functions it seems like it does
what you want?
temp(798)$ cat decls.h
int a0;
int a1;
temp(799)$ cat foo.c
#include <stdio.h>
static void foo()
{
#include "decls.h"
* * a0 = 1;
* * a1 = 2;
* * printf("a0=%d,a1=%d\n", a0, a1);
}
static void bar()
{
#include "decls.h"
* * a0 = 3;
* * a1 = 4;
* * printf("a0=%d,a1=%d\n", a0, a1);
}
int main(void)
{
* * foo();
* * bar();
* * return 0;}
temp(800)$ gcc -Wall -o foo foo.c
temp(801)$ foo
a0=1,a1=2
a0=3,a1=4
-David

yes but then there compiler will have to do unused variable
optimization and so many warnings in the code. Though I am sure, some
of you will say that first I write such a bad code and then even worry
about the warnings. But the fact is this code ie being written by tool
(i.e. computer) not by me. I certainly write better than them. :-)

--
vipin
The compiler having to optimize unused variables away seems a small
burden, and you could disable the warning in a variety of ways (e.g.
for gcc -Wno-unused). But I like Keith's earlier suggestion to not
emit the code as it is generated but rather accumulate it until the
end of the function then emit the variable declarations followed by
the code. Is there some reason this won't work? If you have odd
limitations on your system you could write the function to a temp file
then write the variables and append the temp file to the main one...

-David
Nov 12 '08 #32

P: n/a
sh.vi...@gmail.com wrote:
....
I think i mentioned it somewhere earlier in my posts, but i repeat it
here. In simple terms I am writing a tool which takes a digital
circuit and writes equivalent C code for it. For simulation purpose.
For analogy it is much like Verilator. Now all the things that apply
to a digital world are applied to me.

There can be circuit of million of gates. Since, I am writing in
C ,which is a sequential programming language, I might want to
evaluate some portion of logic cone prior than other. Different
function have to be written for evaluating each port. There can be
anywhere from 1 to 100 output ports etc.
Sounds to me like an excellent reason to write a single function that
takes, as input, a description of the circuit layout, and calls
appropriate subroutines based upon that description.
Nov 12 '08 #33

P: n/a
jameskuyper <ja*********@verizon.netwrites:
sh.vi...@gmail.com wrote:
...
>I think i mentioned it somewhere earlier in my posts, but i repeat it
here. In simple terms I am writing a tool which takes a digital
circuit and writes equivalent C code for it. For simulation purpose.
For analogy it is much like Verilator. Now all the things that apply
to a digital world are applied to me.

There can be circuit of million of gates. Since, I am writing in
C ,which is a sequential programming language, I might want to
evaluate some portion of logic cone prior than other. Different
function have to be written for evaluating each port. There can be
anywhere from 1 to 100 output ports etc.

Sounds to me like an excellent reason to write a single function that
takes, as input, a description of the circuit layout, and calls
appropriate subroutines based upon that description.
Agreed. And I think there's plenty of circuit emulation software out
there already; a quick Google search turns up the GNU package Gnucap,
and the Gnucap page refers to something called Spice. I don't know
enough to offer an opinion on either.

On the other hand, generating low-level C code that emulates a
specified circuit might have some speed advantages over, in effect,
running an interpreter for a circuit layout "language"; perhaps that's
the whole point of this exercise.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Nov 12 '08 #34

P: n/a
sh******@gmail.com writes:
>>
Why do you need to declare them before their first use?
(There are several good answers to that question.)

I want to make them local to function for better results. will it
compile otherwise ?
>Why do you need to do this by generating C pre-processor code
rather than C code?

b'coz i first know the code that uses the variable and then list of
all the variables. since i am generating the code, that means our tool
writing the C code in file, first the code is written that uses the
varable and then i know at the end of function what my list of
variables conclude. So i want to insert a macro immediately after the
opening brace that will expand to variable declarations later.
Are you aware that you need to define the macro *before* the function.
Whatever mean you are using to achieve that (including #include), you can
use it to have the variables definitions in the function without reaching
line length limit.

Yours,

--
Jean-Marc
Nov 12 '08 #35

P: n/a
Keith Thompson <ks***@mib.orgwrites:
Agreed. And I think there's plenty of circuit emulation software out
there already; a quick Google search turns up the GNU package Gnucap,
and the Gnucap page refers to something called Spice. I don't know
enough to offer an opinion on either.
I don't know about Gnucap but Spice isn't at the same level of abstraction
(to summarize a lot, Spice is analog time, analog signals; what the OP
seems to want is discreet time, discreet signals).

Yours,

--
Jean-Marc
Nov 12 '08 #36

P: n/a
sh******@gmail.com writes:
I think i mentioned it somewhere earlier in my posts, but i repeat it
here. In simple terms I am writing a tool which takes a digital
circuit and writes equivalent C code for it. For simulation purpose.
Why the existing simulators don't suit your needs?

I don't intend to be harsh, but you seem too inexperienced for considering
seriously the simulation of million gates circuits -- while I'm working for
an EDA vendor, I've never touched a simulation engine and I can see that.
There can be circuit of million of gates. Since, I am writing in C ,which
is a sequential programming language, I might want to evaluate some
portion of logic cone prior than other.
Your netlist is a DAG, do a DFS starting with your output.
Different function have to be written for evaluating each port.
Your logical cones probably overlap. You'll reevaluate things, if your
goal is performance, that's not the right approach.
I hope it gives a better feeling about the problem but problem is same
that writing functions for logic cone evaluation while traversing the
digital cicruit and then generating the code such that it uses minimum
number of variables etc.
See how to do register allocation in compiler text books.

Yours,

--
Jean-Marc
Nov 12 '08 #37

This discussion thread is closed

Replies have been disabled for this discussion.