how to make large macro paste the code as it is

[Jean-Marc Bourguet]

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,

 

[s0suk3]

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

 

[Phil Carmody]

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?

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

 

[Ben Bacarisse]

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

Ben Bacarisse <[email protected]> writes:

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.

 

[Phil Carmody]

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

 

[Thad Smith]

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

 

[David Resnick]

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.

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

 

[Nate Eldredge]

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.

 

[Chris M. Thomasson]

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.


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/misc/refcount-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...

 

[Keith Thompson]

Phil Carmody <[email protected]> writes:

Please don't delete attribution lines. I've re-added one here.

I want to make them local to function for better results. will it
compile otherwise ?


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.

Let me see if I understand you correctly. You're generating a bunch
of C source code. You don't know what variables the code will use
until you've finished generating it, but of course you need the
variable declarations to appear before the code that uses it. Is that
correct?

Generate the C code, writing it to file A. Now you know what
declarations you need, so write the declarations to file B. Then
concatenate files B and A, creating something.c, which now contains
the declarations and code in the correct order.

Or you can probably build the whole thing in memory without using
intermediate files.

There's no reason you have to write your data (C code in this case) in
the same order you generated it. You just have to save some of your
data somewhere so you can write it when you need it.

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

Almost certainly not. First, you mean probably "fseek", not "lseek".
But in general you can't insert text into the middle of an existing
file. You *might* be able to use fseek to go back to a previous
position and write more data, but it will overwrite whatever was at
that position; the existing data after that point isn't pushed back.

But there's a far more important question here; somebody may have
already asked it, but if so I missed it.

What exactly are you trying to accomplish?

We get a lot of questions here where someone has an underlying problem
they're trying to solve, and they've decided on a particular approach
to solving it. They then ask how to make that approach work. But,
quite often, if they told us about the original problem, we could
suggest a different approach that would work better.

I suspect that you're taking a wrong approach, but it's impossible to
tell without knowing what your ultimate goal is.

 

[Phil Carmody]

Please don't delete attribution lines. I've re-added one here.

I'm not so attached to my input that I demand attribution all
the time. They were fairly nebulous questions that anyone could
have asked. But, of course, you're right in general.

Let me see if I understand you correctly. You're generating a bunch
of C source code. You don't know what variables the code will use
until you've finished generating it, but of course you need the
variable declarations to appear before the code that uses it. Is that
correct?

Generate the C code, writing it to file A. Now you know what
declarations you need, so write the declarations to file B. Then
concatenate files B and A, creating something.c, which now contains
the declarations and code in the correct order.

That would work.

Alternatively, create, and keep, two files, and just #include
the decl file in the middle of the definition file.

Alternatively, make the decl file and the definition file the
same file, and let the preprocessor do the hard work:

-- 8< --
#if !defined(ONLY_WANT_DECLS)

int foo(int zz)
{
#define ONLY_WANT_DECLS
#include __FILE__
b=zz;
a=b+c; c=d+e; e=f+g; g=h+i; i=a+b;
return i;
}

#else
// ONLY_WANT_DECLS defined
int a, b, c, d, e, f, g, h, i;
#endif
-- 8< --

Whilst I like the above as a hack, I think I'd just stick with 2 files
and a #include.

Phil

 

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

 

[David Resnick]

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.

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

 

[sh.vipin]

Please don't delete attribution lines. I've re-added one here.




Let me see if I understand you correctly. You're generating a bunch
of C source code. You don't know what variables the code will use
until you've finished generating it, but of course you need the
variable declarations to appear before the code that uses it. Is that
correct?

You got it perfect. Problem is absolutely like that. Just we need to
add some more complexity in the sense that I have to write 1000 of
such functions.
some of them may be using 400 local variables, some 4 only. I want all
such functions to have their own local variables, due to performance
issue. (I am not touching a[0] Vs a0 issue here but i will certainly
look into that.) And so as suggested by someone that write all
variables in one file and include that in one function was not very
attractive to me because the function that uses only 4 variables will
give only 396 warning.

Generate the C code, writing it to file A. Now you know what
declarations you need, so write the declarations to file B. Then
concatenate files B and A, creating something.c, which now contains
the declarations and code in the correct order.

Yes it will work and i din;t think about it earlier. But only issue i
see here is when writing 1000 functions in the same file I will have
to
repeat ( 1. create temp file 2. add declaration in a.c 3. append temp
to a.c ) 1000 times.

Or you can probably build the whole thing in memory without using
intermediate files.

There's no reason you have to write your data (C code in this case) in
the same order you generated it. You just have to save some of your
data somewhere so you can write it when you need it.

Yes declaration need not to have an order. They just have to be before
their use. I am saving that data on a graph but this data is also
being populated on the fly when I am generating the code. so even an
extra traversal before generating the code will not work.

Almost certainly not. First, you mean probably "fseek", not "lseek".
But in general you can't insert text into the middle of an existing
file. You *might* be able to use fseek to go back to a previous
position and write more data, but it will overwrite whatever was at
that position; the existing data after that point isn't pushed back.

But there's a far more important question here; somebody may have
already asked it, but if so I missed it.

What exactly are you trying to accomplish?

We get a lot of questions here where someone has an underlying problem
they're trying to solve, and they've decided on a particular approach
to solving it. They then ask how to make that approach work. But,
quite often, if they told us about the original problem, we could
suggest a different approach that would work better.

I suspect that you're taking a wrong approach, but it's impossible to
tell without knowing what your ultimate goal is.

Possibly true. In fact solution through array and repeated
concatenation are welcome pointers for me.

 

[Keith Thompson]

That would work.

Alternatively, create, and keep, two files, and just #include
the decl file in the middle of the definition file.

I thought about that (in fact I wrote up a description and then
deleted it). The problem is (mostly) style. #include is normally
used for headers, i.e., files containing declarations to be included
at the top of a translation unit. This solution uses a #include in
the middle of a function (I think the OP wanted the declarations to be
local to the function containing the code). It's certainly not
*wrong*, but I find it to be a bit of a kludge -- and, in this case,
an unnecessary one.

Alternatively, make the decl file and the definition file the
same file, and let the preprocessor do the hard work:

-- 8< --
#if !defined(ONLY_WANT_DECLS)

int foo(int zz)
{
#define ONLY_WANT_DECLS
#include __FILE__
b=zz;
a=b+c; c=d+e; e=f+g; g=h+i; i=a+b;
return i;
}

#else
// ONLY_WANT_DECLS defined
int a, b, c, d, e, f, g, h, i;
#endif
-- 8< --

"#include __FILE__". I don't think I've ever seen that before.
That's magnificently ugly. }

But I think the OP wanted to do this with multiple functions. This
trick requires putting each function in a separate file -- which might
not be a bad idea, but it's an unnecessary restriction. And the
expansion of __FILE__ isn't guaranteed to be usable in a #include
directive; the standard describes it as "The presumed name of the
current source file (a character string literal)".

Whilst I like the above as a hack, I think I'd just stick with 2 files
and a #include.

The goal is to generate a chunk of C source code, consisting of some
declarations and some statements that use them, using some tool. Both
of the #Include solutions do part of that job in the tool, and part of
it using the C preprocessor. As long as you have to write the tool
anyway, why not have it do all the work? Generating the whole
function definition in a single chunk isn't such a difficult task that
we need to pass off part of the work to the preprocessor. And imagine
that, rather than generating the code, you're writing it manually; you
almost certainly wouldn't use a #include directive. You'd just write
the code and then write the declarations. Why should the tool work
differently?

 

[Keith Thompson]

Let me see if I understand you correctly. You're generating a bunch
of C source code. You don't know what variables the code will use
until you've finished generating it, but of course you need the
variable declarations to appear before the code that uses it. Is that
correct?

You got it perfect. Problem is absolutely like that. Just we need to
add some more complexity in the sense that I have to write 1000 of
such functions.
some of them may be using 400 local variables, some 4 only. I want all
such functions to have their own local variables, due to performance
issue. (I am not touching a[0] Vs a0 issue here but i will certainly
look into that.) And so as suggested by someone that write all
variables in one file and include that in one function was not very
attractive to me because the function that uses only 4 variables will
give only 396 warning.

So, to refine the description a bit, you want to do the following:

Repeat 1000 times:
Generate code.
Based on what you learned while generating the code, generate
variable declarations (4 to 400 of them).
Put the declarations and the code (in that order!) into a
function definition.

So the end result is going to be a (really big!) C source file
containing 1000 function definitions.

(You *could* put each function definition in its own separate source
file, compiling each one individually and linking them all together
into your final program. I don't know enough about your underlying
problem to know whether this would be a better approach. It should
work either way.)

Yes it will work and i din;t think about it earlier. But only issue
i see here is when writing 1000 functions in the same file I will
have to repeat ( 1. create temp file 2. add declaration in a.c
3. append temp to a.c ) 1000 times.

Yes, and why is this a problem? This is exactly the kind of tedious
work that computers are good at. (If you use temp files, don't forget
to clean them up.) Or, as I suggested, you might be able to store the
code in memory rather than writing it to a temporary file. That might
speed things up substantially. Do whichever is more convenient.

Yes declaration need not to have an order. They just have to be before
their use. I am saving that data on a graph but this data is also
being populated on the fly when I am generating the code. so even an
extra traversal before generating the code will not work.

Sorry, I didn't quite follow that.

Possibly true. In fact solution through array and repeated
concatenation are welcome pointers for me.

And I still have no idea what your underlying problem is. You're
assuming a particular solution, but if we knew the problem we might be
able to suggest a completely different approach. (Or not.)

One vague thought: You're writing 1000 functions, with up to hundreds
of variables in each. This whole thing is presumably a representation
of something in your problem space. Would it make more sense to
represent it all as data rather than code? Again, without knowing
what problem you're trying to solve, I can't be more specific.

 

[sh.vipin]

You got it perfect. Problem is absolutely like that. Just we need to
add some more complexity in the sense that I have to write 1000 of
such functions.
some of them may be using 400 local variables, some 4 only. I want all
such functions to have their own local variables, due to performance
issue. (I am not touching a[0] Vs a0 issue here but i will certainly
look into that.) And so as suggested by someone that write all
variables in one file and include that in one function was not very
attractive to me because the function that uses only 4 variables will
give only 396 warning.

So, to refine the description a bit, you want to do the following:

    Repeat 1000 times:
        Generate code.
        Based on what you learned while generating the code, generate
        variable declarations (4 to 400 of them).
        Put the declarations and the code (in that order!) into a
        function definition.

So the end result is going to be a (really big!) C source file
containing 1000 function definitions.

(You *could* put each function definition in its own separate source
file, compiling each one individually and linking them all together
into your final program.  I don't know enough about your underlying
problem to know whether this would be a better approach.  It should
work either way.)

Yes it will work and i din;t think about it earlier. But only issue
i see here is when writing 1000 functions in the same file I will
have to repeat ( 1. create temp file 2. add declaration in a.c
3. append temp to a.c ) 1000 times.

Yes, and why is this a problem?  This is exactly the kind of tedious
work that computers are good at.  (If you use temp files, don't forget
to clean them up.)  Or, as I suggested, you might be able to store the
code in memory rather than writing it to a temporary file.  That might
speed things up substantially.  Do whichever is more convenient.

Yes declaration need not to have an order. They just have to be before
their use. I am saving that data on a graph but this data is also
being populated on the fly when I am generating the code. so even an
extra traversal before generating the code will not work.

Sorry, I didn't quite follow that.

Possibly true. In fact solution through array and repeated
concatenation are welcome pointers for me.

And I still have no idea what your underlying problem is.  You're
assuming a particular solution, but if we knew the problem we might be
able to suggest a completely different approach.  (Or not.)

One vague thought: You're writing 1000 functions, with up to hundreds
of variables in each.  This whole thing is presumably a representation
of something in your problem space.  Would it make more sense to
represent it all as data rather than code?  Again, without knowing
what problem you're trying to solve, I can't be more specific.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <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"

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.

Just those simple things. 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.

 

[jameskuyper]

(e-mail address removed) 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.

 

[Keith Thompson]

(e-mail address removed) wrote:
...

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.