how to make large macro paste the code as it is

[sh.vipin]

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 : ??

 

[Ben Bacarisse]

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!

 

[Tomás Ó hÉilidhe]

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

 

[Nick Keighley]

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

 

[sh.vipin]

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.

Do u agree? please give your feedback.

 

[sh.vipin]

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?

 

[sh.vipin]

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();
}

 

[Ben Bacarisse]

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 Bacarisse]

On Nov 11, 6:39 pm, Nick Keighley <[email protected]>
wrote:

yes, unfortunately i need them.

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

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

 

[Bartc]

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.

 

[James Kuyper]

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.

 

[James Kuyper]

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

 

[Erik Trulsson]

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

 

[Bartc]

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"

 

[Nick Keighley]

On 11 Nov, 12:59, (e-mail address removed) wrote:

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?

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?

 

[Phil Carmody]

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

 

[Phil Carmody]

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

 

[sh.vipin]

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"

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.

 

[sh.vipin]

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

 

[Ben Bacarisse]

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

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