How do you rewrite codes with " ... va_list va_start va_etc"?

[mainargv]

hi

How do you rewrite codes with " ... va_list va_start va_etc", so that
simple c compiler don't have to deal with them. I have written a
simple c->verilog compiler but it can't deal with variable length
arguments. How do you rewrite codes with " ... va_list va_start
va_etc"? I guess (I'm not too sure) maybe it's easier to rewrite the c
code if possible? Modifiying my compiler would mean too much work
right now. I have malloc to deal with too (this one is easy for me.)
Thanks.

[mainargv]

On Mar 6, 9:49 am, [e-mail] wrote:

hi

How do you rewrite codes with " ... va_list va_start va_etc", so that
simple c compiler don't have to deal with them. I have written a
simple c->verilog compiler but it can't deal with variable length
arguments. How do you rewrite codes with " ... va_list va_start
va_etc"? I guess (I'm not too sure) maybe it's easier to rewrite the c
code if possible? Modifiying my compiler would mean too much work
right now. I have malloc to deal with too (this one is easy for me.)
Thanks.

Mt thinking right now is this, because there is one more argument
before "...",
I could cast that into "char*" or "void*" and use my own version of
va_*. Any suggestion? I not entirely sure if it's possible without
compiler support. thanks.

[Dave Vandervies]

In article <11**********************@q40g2000cwq.googlegroups .com>,
<ma******@yahoo.comwrote:

>On Mar 6, 9:49 am, [e-mail] wrote:

>hi

How do you rewrite codes with " ... va_list va_start va_etc", so that
simple c compiler don't have to deal with them. I have written a
simple c->verilog compiler but it can't deal with variable length
arguments. How do you rewrite codes with " ... va_list va_start
va_etc"? I guess (I'm not too sure) maybe it's easier to rewrite the c
code if possible? Modifiying my compiler would mean too much work
right now. I have malloc to deal with too (this one is easy for me.)
Thanks.

Mt thinking right now is this, because there is one more argument
before "...",
I could cast that into "char*" or "void*" and use my own version of
va_*. Any suggestion? I not entirely sure if it's possible without
compiler support. thanks.

If you know how to find the arguments (if you're the implementor,
you'd better know this, and if it's somebody else's "simple" compiler it
shouldn't be too hard to discover it by looking at the generated code),
and if you can write appropriate magic that you can hide behind the
va_foo macros to access them without compiler support, you can implement
varargs without making changes to the compiler.

I suspect you may be asking the wrong question (what are you Really
Trying To Do?), but if you're intending to ask what it looks to me like
you are asking, examining an existing implementation's stdarg.h macros
might provide some useful clues.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

>Void pointers will automatically be converted to the right type when the
assignment is made. --Simon Biber and

Or to the wrong type, as the case may be. Kaz Kylheku in CLC

[mainargv]

On Mar 6, 10:14 am, [e-mail] (Dave
Vandervies) wrote:

In article <[e-mail] .com>,

<[e-mail]:

On Mar 6, 9:49 am, [e-mail] wrote:

hi

How do you rewrite codes with " ... va_list va_start va_etc", so that
simple c compiler don't have to deal with them. I have written a
simple c->verilog compiler but it can't deal with variable length
arguments. How do you rewrite codes with " ... va_list va_start
va_etc"? I guess (I'm not too sure) maybe it's easier to rewrite the c
code if possible? Modifiying my compiler would mean too much work
right now. I have malloc to deal with too (this one is easy for me.)
Thanks.

Mt thinking right now is this, because there is one more argument
before "...",
I could cast that into "char*" or "void*" and use my own version of
va_*. Any suggestion? I not entirely sure if it's possible without
compiler support. thanks.

If you know how to find the arguments (if you're the implementor,

I was not the implementer for the frontend, I only wrote the backend.
I didn't want to deal with "..." when I wrote the backend, and still
feel lazy about deal with it if I can get away with rewriting codes.
(there is only one function needs it.)
Rewriting the backend would require me to go through my own spagetti
codes which was horrible
when I wrote that backend. That was like three years ago. my code was
based on suif if you have to know. Anyway linux's inventor had to deal
with this one when he was a student I guess I have to. I had a feeling
I had to deal with this when I wrote that backend, things that are
difficult to untangle between OS and compiler. Since my original
compiler was only meant to compiler simple code for fpga target, I
promptly ignored that case. I would appreciate if people respond with
more info on the issues involved in dealing with it. Like, give me
hints on what's the fastest way to deal with it. Because obviously I
have two ways to deal with it right now. Anyone with experience on
this please respond. I know this is not entirely a language issue...

you'd better know this, and if it's somebody else's "simple" compiler it

The frontend was not a simple project, it's a university reserch
project.

shouldn't be too hard to discover it by looking at the generated code),

I'm the one who was generating the code, and I had no idea how to deal
with it back then.

and if you can write appropriate magic that you can hide behind the
va_foo macros to access them without compiler support, you can implement
varargs without making changes to the compiler.

So you are saying it's possible to modify the va_* codes without
touching the compiler.
(There is no OS to speak of anyway.)

Do you know more on the interplay between OS and compiler on this va_*
issues?

>
I suspect you may be asking the wrong question (what are you Really
Trying To Do?), but if you're intending to ask what it looks to me like
you are asking, examining an existing implementation's stdarg.h macros
might provide some useful clues.

If you know, why don't you just tell the issues involved? thanks.

>
dave

--
Dave Vandervies [e-mail]>Void pointers will automatically be converted to the right type when the

assignment is made. --Simon Biber and

Or to the wrong type, as the case may be. Kaz Kylheku in CLC

[mainargv]

On Mar 6, 10:14 am, [e-mail] (Dave
Vandervies) wrote:

In article <[e-mail] .com>,

<[e-mail]:

On Mar 6, 9:49 am, [e-mail] wrote:

hi

How do you rewrite codes with " ... va_list va_start va_etc", so that
simple c compiler don't have to deal with them. I have written a
simple c->verilog compiler but it can't deal with variable length
arguments. How do you rewrite codes with " ... va_list va_start
va_etc"? I guess (I'm not too sure) maybe it's easier to rewrite the c
code if possible? Modifiying my compiler would mean too much work
right now. I have malloc to deal with too (this one is easy for me.)
Thanks.

Mt thinking right now is this, because there is one more argument
before "...",
I could cast that into "char*" or "void*" and use my own version of
va_*. Any suggestion? I not entirely sure if it's possible without
compiler support. thanks.

If you know how to find the arguments (if you're the implementor,
you'd better know this, and if it's somebody else's "simple" compiler it
shouldn't be too hard to discover it by looking at the generated code),
and if you can write appropriate magic that you can hide behind the
va_foo macros to access them without compiler support, you can implement
varargs without making changes to the compiler.

I suspect you may be asking the wrong question (what are you Really
Trying To Do?), but if you're intending to ask what it looks to me like
you are asking, examining an existing implementation's stdarg.h macros
might provide some useful clues.

I just realized this can be done without touching compiler or other
kludge :)
Since in my case, the argument list is always 1..3 arguments, no
degenerate cases. no kludge required, thanks wanyway.

>
dave

--
Dave Vandervies [e-mail]>Void pointers will automatically be converted to the right type when the

assignment is made. --Simon Biber and

Or to the wrong type, as the case may be. Kaz Kylheku in CLC